Klicken Sie auf den unteren Button, um den Inhalt von podcasters.spotify.com zu laden.

Inhalt laden

Wir haben Falko Werner zu Gast, mit dem wir uns über Skalierung in DevOps unterhalten: warum muß man skalieren (oder nicht?), wie geht man es an, sowie ein Überblick über verschiedene Skalierungsframeworks wie SAFe, LeSS, Flow Framework und einige weitere.

In dieser Podcast-Episode werden verschiedene Aspekte der Skalierung in DevOps erörtert. Die Gastgeber und ihre Gäste, erfahrene Trainer und Berater im Bereich DevOps, tauchen tief in die Theorie und Praxis der Skalierung ein. Sie diskutieren eine Reihe von Frameworks wie SAFe, LESS, Nexus und andere, und wie diese in verschiedenen organisatorischen Kontexten angewendet werden können. Es wird betont, dass die Wahl des richtigen Frameworks von den spezifischen Bedürfnissen eines Unternehmens abhängt und wie wichtig es ist, Agilität und Wertschöpfungsketten über die IT hinaus in die gesamte Organisation zu integrieren.

Inhalt

• Grundlagen der DevOps-Skalierung
• Verschiedene Skalierungsframeworks (SAFe, LESS, Nexus, ITIL 4, usw.)
• Anpassung von Frameworks an Unternehmensbedürfnisse
• Bedeutung von Agilität und Wertschöpfungsketten in Unternehmen
• Diskussion über die Praxiserfahrungen mit diesen Frameworks
• Der Einfluss der IT auf die Unternehmenswertschöpfung
• Kritik und Verteidigung von SAFe als agiles Framework

Shownotes:

https://vempio.de/produkt/skalierung-von-devops-deutsch/

Transkript (automatisiert erstellt, wer Fehler findet darf sie behalten)

Die Sendung wurde vom hr untertitelt.
Hallo und herzlich willkommen zu einer neuen Folge des Podcasts
DevOps auf die Ohren und ins Hirn.
Gestaltet und produziert von Luca Ingianni und Dierk Söllner.
Wir sind DevOps-Trainer und Coaches mit langjähriger Erfahrung.
DevOps umfasst für uns beide kulturelle, organisatorische und technische Aspekte.
Diese diskutieren wir mit Experten aus der Praxis oder in einer gemeinsamen Folge.
Heute haben wir ein etwas ungewöhnliches Setting,
denn Dirk, der ja der Gründer dieses Podcasts immer ist,
ist in Anführungszeichen nur als Gast hier.
Zusammen mit unserem lieben Freund Falko Werner.
Und mit den beiden möchte ich heute als Gastgeber
über das Thema DevOps skalieren sprechen.
Hallo Dirk, hallo Falko.
Hallo.
Hallo Luca, hallo Falko.
Falko, wer bist du denn eigentlich?
Wie, wer bin ich?
Ich bin schon zum zweiten Mal bei euch im Podcast.
Ich bin bereit.
Ich bin ein Berater, Coach, Trainer im Umfeld von verschiedenen Unternehmen,
die agile Arbeitsweisen vorantreiben.
Viel in der Automotive-Bereich, Mobilität, Car-Bike-Sharing und so weiter.
Also ganz viele verschiedene Sichten.
Auch in verschiedenen Rollen bin ich da unterwegs.
Auch als Architekt teilweise.
Und ich freue mich, dass ich zu Gast bin.
Und das in einer ganz besonderen Folge.
Luca, du musst noch einen Tusch nachher rein moderieren.
Also 50. Folge, das finde ich, muss man auch erst mal erreichen beim Podcast.
Ja, allerdings.
Wie viele Jahre sind das jetzt?
Das sind drei Jahre oder so, ne?
Ich glaube ja, es sind ja zwölf pro Jahr.
Also rechnerisch sind das sogar fast schon vier Jahre.
Ja, das ist sehr respektabel, finde ich, für den Podcast.
Müssen wir nachher irgendwie noch ein Champagner aufmachen oder sowas.
Plopp, plopp.
Genau.
Und für heute hatten wir uns ja vorgenommen, über das Thema Skalieren zu sprechen.
Und wir sind draufgekommen, dass das ein so spannendes und umfangreiches Thema ist,
dass wir direkt gesagt haben, wir machen da von vornherein zwei Folgen daraus.
Das bedeutet, ihr werdet heute die erste Folge zum Thema Skalieren hören.
Wo wir so ein bisschen über die Grundlagen sprechen.
Worum geht es denn?
Verschiedene Frameworks.
Warum sollte man überhaupt skalieren?
Muss man überhaupt skalieren?
Und dann in der zweiten Folge wollen wir uns ein bisschen mehr mit den, ich sag mal, praktischen Aspekten beschäftigen.
Wie macht man so eine Skalierung eigentlich?
Welche Schwierigkeiten können auftreten?
Welche Erfahrungen habt ihr schon gemacht?
Welche Erfahrungen habt ihr auch aus euren Trainings vielleicht beizusteuern?
Nicht zu vergessen, wir haben ja auch ein sehr cooles,
Trainings über DevOps skalieren.
Das ist so ein bisschen der Fahrplan für diese und die nächste Folge des Podcasts.
Insofern, lasst uns doch direkt reinspringen.
Wieso muss ich denn eigentlich skalieren?
Oder was ist denn skalieren?
Wieso muss ich das machen?
Okay, skalieren.
Warum müssen wir überhaupt skalieren?
Das ist natürlich die richtige Frage.
DevOps heißt natürlich, geht in Richtung Teamorganisation.
Und ich bringe also alle Funktionen, alles,
alles Wissen in ein Team für Dev und für Ops.
Selbst wenn ich nicht DevOps mache, wenn ich nur ein agiles Team habe,
was vielleicht rein in der Entwicklung tätig ist.
Irgendwo habe ich Grenzen.
Das heißt, die Grenzen liegen letzten Endes in der Teamgröße.
Und eigentlich reden wir schon über skalieren, also darüber, dass mehrere Teams zusammenarbeiten müssen,
dass ich die Zusammenarbeit organisieren muss, wenn ich zwei Teams habe.
Das heißt, rein von der Theorie her, skaliere ich ja schon, wenn ich mit zwei agilen Teams arbeite.
Und, ähm,
wie gesagt, in der Praxis, gerade wenn wir über DevOps reden, gibt es eigentlich ja immer mehr als ein Team.
Ähm, es gibt vielleicht auch eine Entwicklungsmannschaft, die irgendwie agil arbeitet.
Dann gibt es den Betrieb noch, es gibt noch IT-Infrastruktur, die auch irgendwie zusammengebracht werden müssen.
Also wir reden eigentlich immer darüber, dass wir verschiedene Gruppen, dass wir mehrere Menschen zusammenbringen.
Und das ist für mich skalieren.
Sehe ich letztendlich auch so.
Skalierung ist ein Begriff, der meist dann zusammen, ähm, ja, auftaucht, wenn man,
ähm, mit mehr als einem Team arbeitet.
Aber eigentlich ist ja schon die Arbeit im, im Team, ähm, eine Skalierung.
Und zwar die erste Ebene, ähm, von den Individuen hin zum Team.
Und im DevOps-Umfeld wird halt häufig, ähm, von cross-funktionalen Teams gesprochen,
die einen gewissen, ähm, ja, Bereich abdecken können von einem Produkt, von, ähm, Inhalten.
Und, ähm,
üblicherweise geht’s dann, wenn man über mehrere Teams spricht, in den Bereich der, der Skalierung, ähm, von den,
von der wir hier, ähm, reden, wenn wir sagen, wir skalieren DevOps.
Das bedeutet, ein Team ist sowieso schon die erste Ebene von Skalierung, weil einer, einer macht alles allein.
Das wäre sozusagen die einfachste Lösung, ne?
Ja.
Wenn das nicht mehr geht, schnalle ich mir mehrere Leute in ein Team.
Und wenn das auch nicht mehr geht, dann mache ich mir ein Team von Teams.
Zum Beispiel.
Ja.
Und aus meiner Sicht ist das Thema Skalieren bei DevOps, ähm, ja, vielleicht besonders sichtbar, weil eben auch aus meiner Sicht die, die Unternehmen,
wo wir als Trainer und, und Coaches und Berater unterwegs sind, in der Regel ja auch größere Unternehmen sind.
Das heißt, sind Unternehmen, die schon seit vielen Jahren agile Ansätze, ähm, und agile Methoden verfolgen, die ihre Erfahrungen gemacht haben,
wie diese Teams zusammenarbeiten, die an vielen Stellen auch schon seit Jahren unterwegs sind, ähm, diese agile Arbeit in den Entwicklungsteams zu skalieren.
Skalieren, also auszudehnen, Zusammenarbeit sicherzustellen, und jetzt kommen wir eben dann mit dem Thema Betrieb um die Ecke.
Das heißt, die Unternehmen möchten, das ist immer meine Wahrnehmung zumindest, irgendwie auch versuchen, den Betrieb mit reinzubringen, also DevOps.
Insofern kommt, glaube ich, auch das Thema Skalieren im DevOps-Umfeld mit dazu, weil eben der Bereich Dev jetzt in Richtung Ops, ich sag mal, die Fühle ausstreckt, um zusammenzuarbeiten.
Insofern hat man dann halt auch das, was man wertvoll findet.
Ja, genau.
Genau.
Dass man eine vertikale Skalierung hat letztendlich, dass man von Teams, die üblicherweise von, ähm, einem Bereich her, äh, zusammenarbeiten, häufig Entwicklung, meist kombiniert mit Testing,
dann halt von dem Wertstrom auch mehr abgedeckt wird in Richtung Operations, was du gerade meintest.
Aber jetzt muss ich doch mal ein bisschen ketzerisch sein und fragen, ähm, wenn’s bei DevOps auch sehr stark um Autonomie geht, was ich ja immer wieder höre,
inwieweit müssen diese Teams denn dann überhaupt zusammenarbeiten?
Kann ich nicht einfach skalieren, indem ich sage, ich steck hier, keine Ahnung, 20 autonome Teams nebeneinander und die machen halt jeder so irgendwie ihr Ding?
Kann man machen, wird aber nicht zum Ziel führen.
Ich glaub, das ist natürlich wirklich eine, eine ketzerische Frage, aber ich glaub, jeder, der so halbwegs in der, in der betrieblichen Umfeld, äh, unterwegs ist, der wird sagen, alles klar, die werden irgendwas machen, aber die werden, ähm, selten gut zusammenarbeiten.
Und das, was Falco ja eben auch sagte, ähm.
Ja.
Wir haben ja auch, ähm, immer diese, diese Freiheiten in den Teams, die sind super wichtig, ähm, aber ich muss natürlich schon dafür sorgen, dass, wenn ich skaliere, also wenn mehrere Teams zusammenarbeiten, dass sie auf ein gemeinsames Ziel hinarbeiten, dass sie, ähm, auch gemeinsame, ähm, Regelungen haben, wie sie arbeiten, wie sie sich abstimmen, das Thema Schnittstellen.
Also, ähm, ich kenn dich ja, Luca, das war sicherlich keine ernst gemeinte Frage, es war eine richtig schöne, ketzerische Frage, aber es wird nicht funktionieren.
Wenn die, wenn die Teams einfach so, ähm.
Wenn die Teams einfach so machen lasse.
Okay, also einfach so machen lassen geht nicht.
Schade eigentlich, aber du hast recht, wäre natürlich ein bisschen zu schön gewesen, ne?
Und daher kommen wohl dann diese ganzen verschiedenen Ansätze der Eskalierung, dass man sagt, wie kriege ich, wie, wie kann ich ein gemeinsames Regelwerk verfassen, oder?
Für mehrere Teams, mehrere, ich weiß auch nicht, ähm, auch Architektureinheiten nicht zuletzt, ne?
Weil es, es geht ja auch immer um das berühmte Conway’s Law.
Die Dinge, die ich da mache im Kontext der Organisation, die strahlen ja aus auf die Architektur.
Und umgekehrt.
Genau.
Das ist auf jeden Fall eine Sicht, die hilfreich ist.
Und zwar, ähm, kann man natürlich Teams einfach machen lassen und dann halt die Probleme aufräumen.
Ähm, oder man kann halt versuchen, schon ein Stück vorzudenken.
Und, ähm, je nachdem, wie man vorgeht, kann man sich auch inspirieren lassen von Erfahrungen, Best Practices, die sich in, in Frameworks widerspiegeln.
Man kommt aber selten drumherum.
Die Probleme, die mit Conway’s Law zusammenhängen, nämlich, ähm, cross-funktionale Teams aufzusetzen, die möglichst miteinander gut arbeiten,
die in ihrer Kommunikationsstruktur natürlich auch bei einem großen Produkt sich in der Produktkommunikationsstruktur wiederfinden.
Das heißt, die Zusammenhänge zwischen der Teamstruktur und der Struktur der Softwarekomponenten, äh, Module in einem großen System, ähm, spiegeln sich halt nach Conway.
Der hat das ja schon seit Ende der 60er-Jahre, äh, untersucht und, äh, mehrfach an verschiedenen Beispielen auch nachgewiesen, dass es so ist und immer wieder auftaucht.
Ähm, das kann man natürlich auch nutzen, um die Teamstrukturen und das vielleicht richtige Framework, äh, rauszusuchen, was die bestimmten Strukturen, die man technisch erreichen will, auch, ähm, organisatorisch unterstützt.
Im besten Fall geht das halt Hand in Hand.
Okay, ähm, aber eine Sache, die mich jetzt immer noch so ein bisschen beschäftigt.
Ist immer noch, ab wann muss ich denn eigentlich skalieren?
Weil du hast ja, du hast ja auch gesagt, nein, man kann ja auch den Ansatz wählen zu sagen, wir lassen einfach mal alle Teams machen und hinterher fegen wir die Scherben zusammen.
Das klingt jetzt natürlich sehr negativ, aber ich könnte mir vorstellen, zum Beispiel, wenn ich zwei Teams habe, ist das eigentlich gar kein schlechter Ansatz, dass man, dass man die erstmal so ein bisschen machen lässt und denen gar nicht so ein strenges Korsett vorgibt.
Oder sehe ich das, stelle ich mir das zu einfach vor?
Das ist auf jeden Fall eine Variante.
Je weniger Teams oder je kleiner.
Das Produkt ist oder die Teams, die an dem Produkt arbeiten, ähm, sich aufteilen, desto einfacher wird es wahrscheinlich auch, was die Kommunikationsstrukturen und, ähm, die Frameworks angeht, die man dafür einsetzt.
Es gibt auch bestimmte Vorgaben von den Frameworks, in welchem Bereich sie einsetzbar sind.
Zum Beispiel, ähm, ein, ähm, Nexus, das sagt, bis zu acht Teams kann man gut in einem, ähm, für ein Produkt zusammenbringen, ähm, wenn man dieses Framework einsetzen will.
So ähnlich ist auch die Größenordnung bei, bei Less oder für einen agilen Release-Train bei Safe.
Insofern gibt es da ähnliche Größenvorgaben.
Was ich an, an sich ganz…
Was ich an sich ganz interessant finde, wenn man sich die Frameworks mal Stück für Stück, ähm, nebeneinander hält und anschaut.
Okay, ähm, also das fand ich halt schon mal sehr interessant.
Mit anderen Worten, es gibt so gewisse Untergrenzen, unterhalb derer man sich vielleicht das gar nicht antun muss, sich da jetzt systematisch mit Skalierungsframeworks und so auseinanderzusetzen?
Mal, das würde ich, wenn ich auf unsere, auf unsere Schulung gucke und auf die Frameworks, die wir da vergleichen, ähm, würde ich das ein bisschen, ähm, ja, in Frage stellen.
Also, ähm, eine, eine Untergrenze würde ich, wenn ich jetzt rein die Frameworks anschaue, die wir uns, ähm, und die wir untersucht haben, die wir in der Schulung behandeln, würde ich sagen, es geht auch schon mit 15 oder 20, ähm, Teilnehmern.
Wir haben hier ein Framework mit dabei, was letzten Endes nur dafür geschaffen ist, ein, ähm, ein, ein, ein Team abzudecken, also ein Team zu skalieren, ohne dass ich mehrere Teams, ähm, habe.
Also, wir reden da über, über Floating Teams als Ansatz zu sagen, wir haben also…
Es bleibt ein Team, was bis zu 30 Teilnehmer hat, es bleibt ein Team und ich skaliere quasi in diesem Team.
Also, insofern, wenn ich, wenn wir auf eine Untergrenze gehen, würde ich sagen, 30, einfach um mal eine Zahl rauszuhauen.
Ich weiß nicht, wie, wie Falco das sieht, aber ich würde mal die Zahl 30 raushauen.
Ja, ich denke auch, dass da verschiedene Frameworks unterschiedliche Grenzen ziehen, aber 30 ist ungefähr, ähm, eine gute Basis, um, um zu starten und, ähm, muss dann halt schauen, wie groß der Bereich ist, den man da,
ähm, zusammenfassen will und dann gibt’s halt auch gewisse Obergrenzen für bestimmte Skalierungsebenen, wenn man halt vom, ähm, Individuum von dem einzelnen Teammitglied über das Team geht.
Da gibt’s ja auch gewisse Grenzen. So ein Team sollte ja üblicherweise nicht weniger als drei oder fünf, äh, Mitglieder haben, aber auch nicht mehr als, ähm, elf oder, ja, vielleicht manchmal auch in Ausnahmefällen 15.
So ähnlich ist es dann bei den, ähm, Skalierungsfällen.
Frameworks natürlich auch, dass sie auch eine, eine Obergrenze für ihr, für bestimmte Bereiche haben oder dass man dann, ähm, weitere Skalierungsebenen halt einfügen muss, die dann gewisse Strukturen auch unterstützen.
Aber mit 30 als, als Grundlage zu starten, man sollte nicht drüber, man muss nicht über Skalieren nachdenken, ähm, wenn man halt unter der Größe ist oder da macht’s halt Sinn, drüber nachzudenken.
Es gibt auch so ein schönes Zitat, ähm, wenn du skalieren willst.
Mach’s nicht. Oder auf Englisch, if you want to fail, don’t.
Das musst du mir erklären. Ich höre das zum ersten Mal.
Okay. Also wenn man letztendlich Skalieren, also Frameworkstrukturen nutzen will, die, ähm, sich an den Skalierungsansätzen und Frameworks orientieren, einfach nur des Frameworks wegen oder weil’s halt, ähm, schön ist oder weil man das mal ausprobieren will, dann hat man damit eine ganze Menge Overhead.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
war, so 30 Teammitglieder an einem Produkt anzuwirken und gehen dann halt relativ weit
hoch, im schlimmsten Fall halt bis in den ganzen Konzern.
Ja, und ich wollte mal auf deine Eingangsfrage zurückkommen, Luca.
Du hast ja vorhin gesprochen, wann muss man denn skalieren?
Und das, was Falco eben mit diesem Zitat so schön gesagt hat, finde ich, das kann man
da auf jeden Fall nochmal aufgreifen.
Denn letzten Endes muss man nicht skalieren.
Man muss schon gar nicht skalieren, weil es ein tolles Skalierungsframework gibt, was
der gute Kumpel auch gerade irgendwie eingesetzt hat.
Das nennt man die Golfplatzentscheidung für mich.
Nein, bin wieder böse.
Also, man muss nicht skalieren, aber ich denke, dass die Unternehmen überall feststellen,
dass sie in Schwierigkeiten laufen, eben in dieser Zusammenarbeit zwischen den Teams.
Das könnten technische Schwierigkeiten sein, das können organisatorische Schwierigkeiten
sein, aber es gibt Schwierigkeiten.
Und dann sollte man sich eben überlegen, was kann.
Was kann man tun, um die Zusammenarbeit zu verbessern?
Und dann reden wir letztendlich schon über Skalieren und reden über Frameworks.
Wir reden über Erfahrungen von anderen Unternehmen, die das schon hinter sich gebracht haben und
zu denen es dann eben die entsprechenden Frameworks gibt.
Und das ist ja auch das Ziel unserer Schulung, dass wir eben versuchen wollen, mit dieser
Zwei-Tages-Schulung verschiedene Frameworks zum Skalieren darzustellen und das eben nicht
um neuen Frameworks darzustellen, sondern das alles mit Fokus auf DevOps.
Also, die Schulung heißt ja auch DevOps skalieren.
Also, was kann ich nutzen?
Welche Möglichkeiten gibt es, wenn ich in einem DevOps-Umfeld eben skalieren möchte?
Wie gesagt, nicht muss, möchte.
Und das ist wie gesagt, das ist der Inhalt unserer Schulung.
Und da stellen wir eben, wie gesagt, diese neuen Frameworks vor.
Aber nochmal nicht, um einfach Frameworks vorzustellen, um viele Frameworks vorzustellen, sondern um aus jedem Framework das darzustellen, was wir auf den
DevOps-Bereich übertragen können.
Okay, aber jetzt möchte ich an der Stelle mal fragen, nachdem wir schon gesagt haben, wenn man skalieren will, dann sollte man es nicht tun.
Aber warum sollte man es denn müssen?
Oder andersrum gefragt, was sind denn so die typischen Probleme, die man vielleicht verspürt, wenn man sich der Situation nähert, dass man jetzt halt doch skalieren muss
und dementsprechend vielleicht sich auch der Hilfe eines Frameworks bedienen soll oder sowas?
Welche Probleme lösen denn Frameworks?
Welche Probleme löst denn diese Skalierung?
Letztendlich sind es Probleme, die in Richtung Zusammenarbeit gehen, Kommunikationsprobleme, Alignment, insofern, dass alle Teams, die an einem Produkt arbeiten,
voneinander wissen müssen, dass es Abhängigkeiten gibt, dass man über die Abhängigkeiten dann redet, miteinander ins Gespräch geht und sie versucht zu lösen,
planerisch meist, dass bestimmte Dinge von einem Team geliefert werden müssen.
Und die eine Grundlage für ein weiteres Team sind, darauf aufzubauen, dass man sich da über Zeiten abstimmt.
Und da helfen Frameworks, diese Kommunikationsprozesse und Strukturen zu etablieren, um das Ganze ein Stück rund zu machen.
Wenn man das also nicht tut, hat man einen gewissen Chaos-Bereich, in dem man dann unterwegs ist.
Dann wartet ein Team vielleicht Wochen oder Monate darauf, dass ein anderes Team eine zulässt.
Wenn man dann eine Lösung bringt, die benötigt wird, die das Team selbst aber vielleicht aufgrund von Kompetenzen oder vielleicht auch Verantwortungsbereichen nicht übernehmen kann und selbst lösen kann,
weil es zum Beispiel sowas wie gemeinsames Produktverständnis, eine gemeinsame Software-Code-Basis oder ähnliches nicht gibt.
Ein Team hat eine bestimmte Ruhe für eine Komponente und solche Themen kommen dann halt in die Diskussion und führen dann vielleicht auch im Rahmen von einem skalierten Vorgehen
darauf hin, dass jemand, der sich für die Zusammenarbeit und die Performance der Teams Gedanken macht,
sowas wie ein Scrum-Master auf Team-Ebene oder wenn man sich bei SAFe vielleicht orientiert, ein Release-Train-Engineer,
Impediments halt sieht, die man dann halt lösen würde, wofür es dann aber ohne so ein Framework, ohne diese Rollen, ohne diese Verantwortung niemanden gäbe.
Und dann bleibt halt vieles liegen und man hat halt keinen gemeinsamen Fortschritt.
Man weist.
Man weist nicht, wo man jetzt wirklich wichtig an irgendetwas arbeiten muss, damit es für das Unternehmen oder dann auch für die Kunden wieder eine Wertschöpfung gibt.
Und daran kranken halt teilweise auch dann solche unkoordinierten Ansätze.
Also Falco, du hast ja eben ein bisschen was erzählt an dem Ansatz Kommunikation etablieren, Zusammenarbeit etablieren.
Ich glaube, dass so der Anspruch oder der…
Der Wunsch nach Skalierung, also nach besserer Zusammenarbeit, dann auch aus dem Business herauskommt, aus dem Management herauskommt,
die dort eben sehen, dass die Konsequenzen dieser schlechten Zusammenarbeit spüren, schlechte Ergebnisse, verzögerte Lieferung, unabgestimmtes Vorgehen.
Das heißt also auch, dass quasi die Kunden der IT, und auf die sollten wir ja auch achten, dass die Kunden der IT eigentlich auch feststellen, es passt nicht.
Naja, aber können die Leute nicht einfach miteinander reden? Ich meine, das ist doch auch okay, auch ganz ohne Skalierungsframeworks.
Tja, hört sich gut an, Luca, aber wenn ich meine Phoenix-Projekt-Simulation mir anschaue, wenn ich meine anderen Simulationen in irgendwelchen Trainings anschaue,
die Leute sind immer ganz überrascht, wie wichtig es ist, miteinander zu reden.
Und dazu muss man irgendwelche Spielchen spielen, ich sage es mal ganz despektierlich, und das muss man wahrscheinlich auch den Leuten klar machen.
Und man muss ihnen wahrscheinlich auch eine…
Ein Hilfsmittel eben an die Hand geben, wie sie diese Kommunikation etablieren können.
Also zu sagen, redet miteinander, reicht wahrscheinlich nicht aus.
Ja, wenn es dann über 15, 20, 100 Beteiligte sind, die in verschiedenen Teams arbeiten, mag dieses Redet doch miteinander ohne Hilfsmittel und ohne Koordination halt dazu führen,
dass du halt nur am Reden bist und erst mal am Suchen bist, mit wem du denn über welches Thema wie reden musst, damit es funktioniert.
Und genau da setzen dann halt die Frameworks an, um da Strukturen zu etablieren, um genau dieses Redet miteinander in eine Form zu bringen, die möglichst wertschöpfend ist.
Ja, das erinnert mich irgendwie auch sehr an eins meiner gegenwärtigen Lieblingsbücher, nämlich Team Topologies, die ja auch sehr rumreiten auf diesem Konzept von ungünstiger Kommunikation.
Man kann ja naiv sagen, ja, ja, Kommunikation ist immer gut und das stimmt ja auch a priori.
Aber es gibt gewisse Teams, die sollten vielleicht nicht miteinander reden müssen oder man sollte eben zum Beispiel nicht sich durchfragen müssen,
bei wem bin ich jetzt an der richtigen Adresse, um folgende Abhängigkeit zu behandeln oder sowas.
Das ist eine Art von schädlicher, von parasitärer Kommunikation, die halt nur Zeit frisst und niemanden weiterbringt.
Wir hätten eigentlich viel wichtigere Sachen, über die wir miteinander reden müssten.
Sprichst ja fast wie jemand, der Agilität nicht mag. Da gibt es ja nur die Meetings, die reden ja nur.
Ja, furchtbar.
Ja.
Ja, aber wenn wir das nochmal aufgreifen, also Kommunikation, hat man gesagt, ist ein Grund für Skalieren, also Kommunikation regeln, Kommunikation einfach in Gang bringen und dann auch zielgerichtet ablaufen lassen.
Das ist, glaube ich, etwas, was wir letzten Endes aus einzelnen Schulungen, also aus Scrum oder DevOps-Schulungen nehmen können und was wir aber genauso in der Skalierungsschulung eben bemerken, dass einfach klar ist, es gibt verschiedene Ansätze.
Wie kann ich skalieren?
Wie kann ich die Kommunikation unterstützen?
Wie kann ich das regeln, dass die Teams miteinander sprechen?
Und das ist, glaube ich, eben ein Punkt, den wir auch in unseren Schulungen oder in der Schulung behandeln, wo wir eben schauen, wie oder vergleichen, wie liefern einzelne Frameworks von diesen neuen einen Beitrag zur Kommunikation?
Wie kann ich einzelne Frameworks nutzen, um dort rauszulesen, ja, wie arbeite ich zusammen und wie kriege ich Alignment hin?
Das, was Falko ja vorhin auch sagte, dass ich ja auch ein Alignment hinbekommen muss.
Dass ich Governance hinbekommen muss.
Das sind alles Punkte, die man aus diesen einzelnen Frameworks rausziehen kann.
Und das ist auch der Versuch in unserer Schulung.
Genau.
Also das finde ich einen ganz tollen Punkt.
Vielleicht kann ich an der Stelle auch gleich einhaken.
Nämlich jetzt haben wir diesen Vergleich gemacht zwischen, ich glaube, neun verschiedenen Frameworks, die wir da einander gegenüberstellen.
Und ich bin wahnsinnig neugierig, was ihr entdeckt habt an bemerkenswerten Gemeinsamkeiten oder auch Unterschieden,
die, über die man vielleicht sprechen sollte an dieser Stelle.
Ja, dann sollten wir vielleicht erstmal anfangen und diese neuen Frameworks benennen.
Weil die meisten unserer Zuhörer werden wahrscheinlich eins kennen, die werden vielleicht zwei kennen.
Und vielleicht ist es ganz hilfreich, da einfach mal zu starten.
Also die neuen Frameworks, die wir im Vergleich sozusagen haben in der Darstellung.
Das erste ist natürlich SAFe, weil es das bekannteste Skalierungsframework ist.
Das zweite wäre LESS.
Auch das kennen noch ziemlich viele.
Ist ein bisschen einfacher, ein bisschen übersichtlicher, aber eben doch auch sehr, sehr hilfreich, um ein bisschen was daraus zu lernen.
Und dann kommt mein Lieblingsframework für Skalierung.
Ich weiß, dass ich mich bei allen Agilisten unbeliebt mache.
Wir haben ITIL 4 auch mit drin.
Natürlich ist ITIL 4 kein Skalierungsframework, aber ich habe ja eine spezielle Schulung dazu.
Und auch in der DevOps-Skalierungsschulung kriegen wir das dargestellt, wie man auch Elemente aus Skalierungsschulungen,
wie man auch Elemente aus Skalierungsschulungen, wie man auch Elemente aus Skalierungsschulungen,
wie man auch Elemente aus ITIL nutzen kann, um agile Teams, um DevOps-Teams zu skalieren.
Und wenn ich dann weiter mal auf der Liste schaue, Scrum at Scale haben wir noch mit dabei.
Das ist das, was Jeff Sutherland entwickelt hat, damals schon vor hunderten von Jahren, als das mit der Skalierung von Scrum schon losging.
Wir haben Nexus mit drin mit dargestellt, was von Ken Schwaber ja entwickelt wurde.
Das sind so die Ansätze, glaube ich, die die meisten auch kennen oder viele, die in der agilen Szene sind, die sich damit beschäftigen.
Das ist das, was Jeff Sutherland entwickelt hat, damals schon vor hunderten von Jahren, als das mit der Skalierung von Scrum schon losging.
Das ist das, was Jeff Sutherland entwickelt hat, damals schon vor hunderten von Jahren, als das mit der Skalierung von Scrum schon losging.
Dann sieht man natürlich auch die Devils, was auch hier zu sehen ist, was gleichzeitigschooliert, easily-elegable ist,
Und wenn man dann weiterschaut, haben wir noch die Flight Levels mit drin von Klaus Leopold.
Und wenn man dann weiterschaut, haben wir noch die Flight Levels mit drin von Klaus Leopold.
Das, finde ich, ist auch ein ganz toller Ansatz, eine ganz tolle Erfindung
Das, finde ich, ist auch ein ganz toller Ansatz, eine ganz tolle Erfindung
Das, finde ich, ist auch eine ganz tolle Ansatz, eine ganz tolle Erfindung
und dass deswegen macht es auch Sinn, das auch mit einzubringen in diese Schulung.
in diese Schulung. Und dann hat
Falco was ganz Tolles entdeckt
von IT Agile aus
Hamburg, das Floating Teams.
Das ist eben das, was wir vorhin schon angedeutet
haben. So ein Ansatz, wie kann
ich denn quasi in einem Team ein bisschen
skalieren? Wie kann ich ein Team
vielleicht bis zu 30 Personen
aufbauen, damit ich nicht anfangen
muss, eben dann Teams auseinanderzureisen?
Ich höre die Scrum-Polizei
schon kommen. Ja, ja. Lass mich
noch die letzten zwei, bevor ich verhaftet werde,
die letzten zwei nennen. Dann haben wir
noch das Flow-Framework von
Mick Kirsten entwickelt. Da gibt es auch eine eigene
Webseite zu. Und auch ein
etwas, ich will nicht sagen dinosaurischer,
aber auch ein Ansatz, der schon
ein paar Jährchen auf dem Buckel hat.
Das ist Disciplined Agile Delivery.
Das ist von Scott Embler entwickelt
worden und ist auch jetzt noch aktuell
am Markt, sag ich mal, verfügbar.
Ist vom PMI übernommen worden.
Also das sind jetzt im Prinzip die neuen Frameworks,
die wir darstellen.
Prima. Und wo wir schon bei der Ketzerei sind.
Dirk hat ja schon sein Lieblings-Framework genannt.
Falco, hast du auch ein Lieblings-Framework?
Mein Lieblings-Framework ist das
Komm-Drauf-An-Framework.
Das Schöne bei den Frameworks ist ja,
dass jedes für sich
einen bestimmten Fokus setzt.
Und das letztendlich
für das Unternehmen
passende ist für mich letztendlich
das, was an der Stelle
besonders gut ist.
Natürlich habe ich
mit verschiedenen Frameworks meine Erfahrungen
gemacht. Das, was am
verbreitetsten ist, mit dem ich halt auch die
meiste Erfahrung gesammelt habe, ist
SAFE. Das, was ich
persönlich am interessantesten
finde,
ist LESS
in Kombination mit
Floating Teams und Flow Framework.
Also ich finde, auch da lassen sich halt
aus verschiedenen Frameworks
spannende Ansätze kombinieren.
Und deswegen kann
ich mich nicht so richtig auf eins
festlegen. Es hat halt
also, wie gesagt, Flow Framework, Floating
Teams und SAFE in Kombination.
Okay, sehr gut.
Sehr schön. Jetzt habt ihr ein paar
spannende Sachen angesprochen oder du
vor allen Dingen, Falco, indem du gesagt hast,
verschiedene Frameworks sind
halt besonders gut für verschiedene
Sachen. Ich meine, wir wollen jetzt nicht
irgendwie mühsam alle neuen Frameworks
durchdeklinieren, aber vielleicht kannst du ein paar
Beispiele liefern, was vielleicht besonders heraussticht.
Eins hast du wahrscheinlich schon gesagt mit den Floating
Teams, was halt sehr
sinnvoll ist für
kleine Gruppen von Leuten, die sich
so ein Riesenframework gar nicht antun
wollen, sondern etwas, ich sage mal
pragmatischer den Ansatz
verwenden wollen. Was gibt es denn noch für spannende
Beispiele von Besonderheiten?
Ja, eines der wenigen
Frameworks, die sich auf ein gesamtes
Unternehmen beziehen,
ist SAFE, also Scaled
Agile Framework, das halt
in den verschiedenen Skalierungsebenen
von der
Team-Ebene in den agilen
Release-Train geht. Auf der Team-Ebene
sagt man halt Scrum, Kanban meist,
vielleicht auch
etwas Kombiniertes
aus Arbeitsweisen auf
Team-Ebene, hat aber
auch viele Inhalte, die
für große Produkte mit
mehreren hundert beteiligten
Mitarbeitern relevant sind
und bringt halt auch
Rollen mit, die
auf den verschiedenen Skalierungsebenen,
die das abbildet,
dann bestimmte Aufgaben übernehmen
und geht halt bis hin
in das Portfolio des Unternehmens
mit dem
ja, mit der
Portfolio-Ebene, bei der
es auch nicht auf ein Portfolio
reduziert, sondern halt auch sagt, ein Unternehmen
kann mehrere Portfolios haben
in verschiedenen Unternehmensbereichen
und bildet sozusagen
einen exemplarischen
Beitrag
für auch
große Konzerne ab,
in denen man letztendlich durchgängig
mit einem Framework arbeiten kann.
Ich glaube, das reicht
für mich als Beispiel für,
für SAVE.
Jedes Framework hat halt seine
Historie, kommt aus irgendeiner bestimmten
Richtung, so ähnlich wie SAVE
und LESS aus der Nokia-Welt kommen.
Nokia
Networks mit LESS
oder Nokia
mit den
Mobiltelefonen-Sparte
haben halt gewisse
Lernkurve gemacht,
die halt für das Unternehmen selbst nicht
so gut gelaufen sind. Anders
ist es halt bei einem Ansatz, den wir
auch mit erwähnen, zum Beispiel
Spotify, die sich halt auch aus ihrem
Spotify-Ansatz
heraus entwickelt haben und halt
weitergegangen sind. Und so sollte man
auch die Frameworks als Ideengeber
sehen, als
Inspiration für eine agile
Entwicklung in einem
Unternehmen. Und da
bietet es sich halt häufig an, aus
einer klassischen Welt heraus
ein recht verbreitetes
Framework zu nutzen, das halt
möglichst viele Ideen schon mitbringt,
an denen man sich halt orientieren kann,
aber eben nicht muss und da auch
nicht festgenagelt sein sollte drauf,
sondern dass man halt das als
guten Startpunkt sieht und
vielleicht mit einem
verbreiteten Framework halt startet
und dann halt schaut, was man auch von
anderen Frameworks sich abschauen
und übernehmen kann und welche Ideen
vielleicht auch besser passen als
aus irgendeinem By-the-Book-Ansatz.
Ich würde nochmal auf dieses
tolle Komm-drauf-an-Framework
eingehen, weil das finde ich echt
ein cooles
Framework, weil
letzten Endes wollen wir das ja auch in der Schulung
unseren Teilnehmern
ermöglichen, sich selbst
ein Das-kommt-drauf-an-Framework zu bilden.
Also wir kommen ja in der Schulung nicht zu einer Aussage,
das ist das beste Framework,
das musst du nehmen oder wenn du
fünf Mitarbeiter hast, dann musst du das nehmen
und wenn du zehn hast, dann musst du das nehmen,
sondern wir stellen ja wirklich die
Frameworks immer aus der DevOps-Sicht
dar. Also es sollte niemand erwarten, dass er
jetzt in zwei Tagen neun Frameworks komplett
nähergebracht bekommt. Also wir
gucken uns den DevOps-Part an
und wenn ich sage, kommt drauf an,
dann ist ja die Frage zum Beispiel,
will ein Unternehmen zentral planen
und zentral steuern weiterhin?
Das ist eine Frage, wo wir
eben dann drauf eingehen und wo wir
darstellen, welches Framework sich dort
vielleicht eher eignet und welches dort sich
eher nicht eignet. Das heißt also,
es wird nicht gesagt,
das ist das beste Framework, was Herr Falco
auch sagte, man startet mit einem
Framework und letzten Endes,
der Start, den wir mit unserer
Schulung bieten wollen, ist der Vergleich
bei bestimmten Punkten. Also zum Beispiel
zentrale Planung, zentrale
Steuerung. Da ist vielleicht SAVE und
ITIL 4 etwas besser geeignet
als LESS oder NEXUS an der Stelle.
Aber wenn ich natürlich nicht zentral
planen will und nicht zentral steuern
will, ja dann passen LESS
und NEXUS vielleicht wieder ein bisschen besser.
Wo wir jetzt so viel
über SAVE gesprochen haben,
wie steht ihr eigentlich zu der
recht verbreiteten Kritik oder
ich höre sie jedenfalls nahezu ununterbrochen,
habe ich das Gefühl, dass SAVE ja überhaupt
kein agiles Framework mehr ist und das ist ja nur
Wasserfall in neuen
Kleidern und überhaupt alles des Teufels.
Vielleicht bist du in der falschen Filterblase
unterwegs, aber jetzt
Spaß beiseite.
Also ich höre das ja auch und
ich stelle fest,
dass die Unternehmen, die sich mit SAVE
beschäftigen, also die skalieren wollen,
dass die schon sich
das genau anschauen, dass sie eben die Vorteile
sehen und letzten
Endes, wenn man jetzt ganz böse ist,
kann man ja auch sagen,
vielleicht ist es ja okay, dass es vielleicht gar
nicht so agil ist, wie
das manche Menschen wollen, wie das manche
Berater wollen, wie das manche Experten
auch wirklich wollen. Vielleicht ist das manchmal auch
dann ein zu großer Anspruch für die Unternehmen.
Also, kurz gesagt,
mir ist das im Prinzip egal. Ich habe meine
Meinung zu SAVE und meine Meinung
ist, dass es schon eine
schöne Sammlung ist von Ansätzen
und ob das unter den Unternehmen
hilft, das müssen die Unternehmen selbst
entscheiden.
Ich würde gerne auf die Frage nochmal zurückkommen
und fragen, was heißt denn
ein agiles Framework? Ist das Framework
nicht agil oder hilft es
Unternehmen nicht dabei
agilär zu werden
oder agil zu werden und wann ist dann
ein Unternehmen agil?
Tja, das weiß ich auch nicht. Ich gebe
nur die Kritik wieder, die ich so höre.
Ja, und mir geht es da glaube ich
so ein bisschen ähnlich wie euch.
Es ist halt nur ein Werkzeug oder nur ein Werkzeugkasten,
und wer sich jetzt mit der Beißzange den Finger
zwickt, der kann natürlich der Zange die Schuld
geben.
Ob das jetzt berechtigt ist oder nicht,
weiß ich auch nicht.
Gut, also ich finde es ganz interessant,
wenn man das Framework betrachtet und
sagt, es ist nicht agil, es
verändert sich ja mit der Zeit. Es wird
ja dazugelernt. Es gibt ja verschiedene
Versionen und eine Weiterentwicklung
über zehn Jahre mittlerweile
und es gibt Elemente,
die sind halt relativ stabil
dabei. Ich finde es aber ganz interessant,
dass halt immer wieder neue Aspekte
auch bei so einem Framework
wie SAVE aufgenommen werden.
Zum Beispiel mit der 5er-Version
halt nochmal den
Kundenfokus ein Stück zu schärfen oder
mit der 5.1er-Version halt
nochmal
bestimmte andere Aspekte wie
die Business-Agilität
in Vordergrund zu stellen und halt zu
sagen, man braucht bestimmte
Kompetenzen,
die wichtig sind, die man mit
aufnehmen muss und dabei
eben auch auf die Wertströme zu
achten, die in einem Unternehmen
relevant sind. Und das sind für mich
schon alles Aspekte, die
in Richtung Agilität
gehen. Ob man jetzt
in der Arbeitsweise dann
auf Projekte in
drei Monatszyklen
oder Quartalszyklen gehen, die dann mit
den SAVE-Programmingrementen übereinstimmen
oder nicht, ist halt immer
eine Frage der Sichtweise.
Im Umfeld von
SAVE gibt es ja große Anforderungen,
die sie im Framework in der
Beschreibung halt bewusst nicht
Projekte nennen, sondern
Epics. Und da gibt es eine schöne
Gegenüberstellung, was der Unterschied ist und was nicht.
Und ja, es gibt
halt eine gewisse Planung und
die ist aber im agilen
Umfeld ja kein
zu ignorierendes oder
zu verteufelndes
Element, sondern das bildet halt
die Grundlage, um darauf halt
wieder neu agieren und
reagieren zu können. Und im
besten Fall besser als ohne die Planung
zu haben. Das heißt,
auch wenn man dann halt mit mehreren
Release Trains,
mehreren hundert Mitarbeitern
so ein Quartal plant
und man dann halt sagt, ja, das ist jetzt
der Wasserfall, zumindest
von der Außensicht heraus, ändert sich
aber in den Unternehmen, die
damit arbeiten, doch eine ganze
Menge. Teamzusammensetzung,
Kommunikationsstrukturen,
der Wertfokus wird
viel mehr erhöht, als das ohne
so ein Framework ist.
Und deswegen sehe ich
letztendlich
an diesen Argumentationen
safe ist nicht agil, auch
Grund, mit den Leuten zu diskutieren
und da mal Erfahrungen zu sammeln. Das heißt,
wenn jemand, der Zuhörer,
das Thema safe ist
nicht agil vertreten möchte
und mit uns dann mal in die Diskussion
gehen mag,
lade ich gerne auch
in persönliches Gespräch
ein oder wenn Luca und Dirk
Lust haben, kann da
vielleicht auch mal noch eine spannende
Folge für den
DevOps auf die Ohren
und ins Hirn Podcast werden.
Ja, das ist eine lustige Idee.
Falls sich jemand bemüßigt fühlt,
feste gegen safe zu schimpfen zum Beispiel,
dann bieten wir ihm hier gerne eine Plattform
und schauen mal,
was jeder vom anderen lernen kann, oder?
Ja, ich würde noch mal
den Punkt aufgreifen von
Falco. Natürlich, es wäre sehr schön,
wenn sich Leute aus diesem Podcast,
aus der Folge heraus,
motiviert fühlen, auch mal zu Gast zu sein
mit ihrem Thema. Das ist der erste Punkt,
der mir wichtig ist.
Und inhaltlich würde ich sagen,
was Falco gerade gesagt hat,
würde ich noch ein bisschen rausarbeiten wollen.
Wenn safe nicht agil ist,
dann ist es vielleicht so,
dass das, was safe mitbringt,
auch vielleicht sozusagen eine nächste,
vielleicht ein bisschen pathetisch gesagt,
Evolutionsstufe ist.
Das heißt, die Frage ist ja, ist Agilität
noch die Antwort auf die,
ähm, aktuellen Herausforderungen?
Also, ich will diese Frage nur in den Raum stellen.
Ich will sie nicht beantworten.
Aber es könnte ja sein, dass das Thema
Value Stream, das Thema Wertschöpfungskettenbetrachtung,
dass das quasi der nächste
Schritt ist, wohin sich Organisationen
hin entwickeln müssen.
Und das wäre vielleicht eine Art
Ablösung oder eine Art
Übergang auf
Value Stream,
also auf eine Wertschöpfungskettenbetrachtung.
Und dann ist Agilität ein Teil davon.
Und warum sage ich das?
Weil ich es eben auch sehr interessant finde,
dass das Thema, das ITIL 4
sich auch in Richtung Wertschöpfungsketten
entwickelt hat. Also,
kurz gesagt, glaube ich, dass es sehr, sehr
hilfreich ist und sehr, sehr interessant ist,
zu gucken, ob Agilität
nicht vielleicht auch in einem Bereich ist,
wo wir über neue Ausrichtungen
nachdenken müssen. Und das könnte ja auch
Value Stream sein.
Ja.
Das finde ich einen ganz tollen Punkt, den du da
angeschnitten hast. Denn, ich hatte mir
auch als Frage notiert,
reicht es denn eigentlich
aus, wenn man diese
Skalierung rein auf
die IT-Organisationen anwendet?
DevOps ist aus meiner Sicht
kein Ansatz,
der sich nur auf
IT-Organisationen bezieht.
Also,
insofern,
bei DevOps, noch bei Agilität,
noch bei
Skalierung,
kann man sich auf
reine IT
beziehen.
Aus meiner Sicht, und
da stimme ich schon ein Stück auch mit
Safe überein, oder anderen
Frameworks, geht es da halt um eine
Ende-zu-Ende-Betrachtung der Wertschöpfung.
Und
da spielt es halt eben genau
rein, sich den
Kunden, den Kundennutzen
oder andere Bereiche
der Wertschöpfung
entsprechend anzuschauen. Kann ja auch
Unternehmensnutzen sein,
Unternehmenswerterhöhung oder ähnliches,
die man versucht zu erreichen.
Und üblicherweise reicht es dann nicht
aus, sich auf die
IT zu beschränken. Es ist häufig
der erste Punkt, an dem agiles
Arbeiten den Einzug
in kleinere, mittlere
und große Unternehmen
hat, oder wo letztendlich
Agilität startet,
zumindest aus meiner Erfahrung, und dann
in andere Bereiche
mit hineinwirkt, bis die
dann letztendlich ins ganze Unternehmen
und häufig auch über
Unternehmensgrenzen hinweg
wirken. Zum Beispiel
zu den Auftraggebern mit
hinein. Bin bei
einem Unternehmen mit
relativ vielen Schulungen unterwegs
und bekomme da halt verschiedene Sichten.
Und da ist halt die öffentliche
Hand der Auftraggeber.
Und wenn sich das Unternehmen
agilisiert, heißt das
natürlich auch, dass dann
andere Gespräche mit Auftraggebern
geführt werden müssen. Dass man sich
dann mit den Anforderern zusammensetzt,
dass man auch Planungszyklen,
dass man die Auftraggeber
in viel engere
Kommunikations- und Feedbackzyklen
einbindet, zum Beispiel Sprintlänge
oder Quartalsergebnisse,
Programmingremente
oder wie auch immer man sich dann sonst organisiert,
dass man da halt
viel engere Gespräche
miteinander
finden muss.
Und genauso wie das
im Unternehmen passiert, passiert es
halt in der Wertschöpfungskette,
auch über Unternehmensgrenzen,
hinweg, auch zu den Auftragnehmern,
die man letztendlich hat. Hat das
eine Veränderung der
Arbeitsweisen und Kommunikationsweisen?
Ja, bringt das halt mit.
Okay. Also mit anderen
Worten, genau meine Vermutung
hast du bestätigt, dass
es ist zwar eine gute Sache,
die IT-Organisationen zu agilisieren,
aber das ist vermutlich nicht
ausreichend. Und ich glaube, das können wir
auch bestätigen aus unserer Beratungs- und
Schulungspraxis, dass das dann ganz häufig
zu Spannungen führt, genau sozusagen an den Außengrenzen
der IT-Organisationen.
Dass die auf einmal
sich ganz anders anfühlt
für den Rest des Unternehmens oder für die Auftraggeber
und die ihrerseits irgendwie
sich auch an diese veränderte
Schnittstelle anpassen müssen
und da vielleicht auch
das eine oder andere Mal ein bisschen daran zu knabbern haben.
Was ich an der Stelle noch ergänzen
möchte, ist, wenn wir von
IT-Organisationen sprechen, es gibt
natürlich den Ansatz, dass immer mehr
Produkte mit immer mehr Anteil
von IT-Wertschöpfung
sich entwickeln.
Und dieses schöne Zitat
Software eats the world
geht so ein Stück in die Richtung,
dass man natürlich auch immer mehr
von der IT
eine Unternehmenstreiber-Funktion
hat und sieht, dass man
halt die Chief Information
Officers, CIOs,
immer mehr an dem
Unternehmenserfolg mit
beteiligt oder mit
einbeziehen muss, um
dann vernünftige Software,
Lösungen, Produkte auch zu ermöglichen
und genau
da kann man natürlich
sagen, steigt der Wert
der IT im Unternehmen, der
Anteil der Wertschöpfung der IT
in den Produkten, man denke nur an
Smartwatches oder
selbstfahrende Fahrzeuge
oder ähnliches, sind halt so
Beispiele, die man sich da vor Augen führen
kann. So ein Stück
spiegelt das natürlich dann auch
diesen Gedanken der Wertschöpfungskette
IT und man startet mit der IT,
um halt besser Wertschöpfen
zu können und das
trägt sich in das Unternehmen hinein,
spiegelt sich da halt wieder.
Okay, wunderbar.
Gibt es denn etwas, worüber ihr gerne noch sprechen würdet
im Rahmen dieser ersten Folge über, ich sage jetzt mal,
die Theorie von Skalierung?
Haben wir was vergessen? Gibt es noch was Spannendes,
was ihr loswerden wollt?
Also ich bin bedient.
Nein, also ich glaube,
dass wir genug über Theorie
gesprochen haben. Wir haben ja, glaube ich, in die Theorie auch schon
viele Sachen eingeflossen oder
einfließen lassen aus der Erfahrung,
aus praktischen Erfahrungen
und ich glaube auch, so eine klare Trennung
in Theorie und Praxis wollen auch die
Zuhörer nicht. Also man kann
sicherlich mal eine Theorie-Folge machen,
aber ich glaube, dass diese Folge, die wir jetzt hier hatten,
aus meiner Sicht eben genug Theorie
hat, aber auch schon sehr viele praktische
Erkenntnisse mit dazu. Also
ich freue mich auf die zweite Folge.
Genau, was ich damit sagen wollte,
sollen wir diese Folge hier beenden und zur nächsten übergehen?
Sehr gerne. Ich glaube, wir sollen.
Dann vielen Dank bis dahin.
Und liebe Zuhörer,
in wenigen Wochen kriegt ihr dann
den zweiten Teil.

Klicken Sie auf den unteren Button, um den Inhalt von podcasters.spotify.com zu laden.

Inhalt laden

Wir haben in dieser Folge Heiko Bartlog zu Gast. Wir sprechen über seinen Blog mit der Liste zum Thema „Die Gesetze der Zusammenarbeit“. Heiko hat eine tolle Sammlung an bekannten und weniger bekannten Gesetzmäßigkeiten zusammengestellt, die Phänomene in der Organisation und Zusammenarbeit beschreiben. In unserem Podcast haben wir bereits Conways Law und auch das Phasenmodell von Tuckman behandelt. Hier folgt nun eine lockere Besprechung weiterer „Gesetze“ wie die von Parkinson und von Hofstadter. Weitere Themen sind der Ringelmann-Effekt, das soziale Faulenzen und die 85/15-Regel von Deming. Interessant sind auch der Sleeper- und Dr. Michael.J. Fox-Effekt.

In dieser Folge des DevOps-Podcasts diskutieren die Teilnehmer über verschiedene Gesetzmäßigkeiten und Theorien, die für die Zusammenarbeit in DevOps und agilen Kontexten relevant sind. Sie betrachten Phänomene wie das Parkinson’s Gesetz, den Ringelmann-Effekt und den Dunning-Kruger-Effekt. Diese Konzepte werden auf ihre Anwendung in der Praxis untersucht, wobei sowohl die technischen als auch die kulturellen und organisatorischen Aspekte von DevOps und agilen Methoden beleuchtet werden. Die Diskussion umfasst auch die Bedeutung von effektiver Kommunikation und Teamdynamiken im Arbeitsumfeld.

Inhalt

• Einführung und Vorstellung der Teilnehmer
• Persönliche Definitionen von DevOps
• Gesetze der Zusammenarbeit
  • Parkinson’s Law
  • Ringelmann-Effekt
  • Dunning-Kruger-Effekt
• Anwendung der Gesetze in der Praxis
• Bedeutung von effektiver Kommunikation und Teamdynamik
• Kognitive Verzerrungen und ihre Relevanz in Teams
• Diskussion über agile Methoden und ihre Auswirkungen
• Abschlussgedanken und Danksagung

Shownotes:

[https://bartlog.de/blog/gesetze-zusammenarbeit]
(Blog: Gesetze der Zusammenarbeit)

Transkript (automatisiert erstellt, wer Fehler findet darf sie behalten)

Hallo und herzlich willkommen zu einer neuen Folge des Podcasts DevOps auf die Ohren und
ins Hirn, gestaltet und produziert von Luca Injani und Dirk Söner.
Wir sind DevOps-Trainer und Coaches mit langjähriger Erfahrung.
DevOps umfasst für uns beide kulturelle, organisatorische und technische Aspekte.
Luca ist leider heute kurzfristig verhindert.
Ich freue mich daher heute quasi alleine auf das Gespräch, auf das Thema, die Gesetze der Zusammenarbeit.
Das klingt natürlich nicht wirklich spannend, aber ich kann euch eine tolle Folge versprechen,
weil ich eben einen tollen und sehr interessanten Gast habe,
nämlich Heiko Bartlok.
Heiko ist Gastgeber für Innovation.
Er schafft Raum, Gelegenheiten und bietet Zutaten für agile Zusammenarbeit und erfolgreiche Innovation.
Ich möchte da an dieser Stelle auch Heiko nochmal danken.
Er ist nämlich kurzfristig eingesprungen.
Also nicht nur Luca ist kurzfristig ausgefallen, auch unser geplanter Gast ist kurzfristig ausgefallen.
Und insofern sind wir dankbar dem Heiko, dass er wirklich kurzfristig eingesprungen ist.
So Heiko, ich habe dich kurz vorgestellt.
Habe ich irgendwas vergessen?
Nein.
Möchtest du noch irgendwas ergänzen?
Also erstmal danke für die Einladung und danke für die Vorstellung.
Und ich freue mich total auf das Gespräch.
Vor allen Dingen zu diesem etwas sonderbaren Thema.
Da bin ich sehr gespannt.
Nee, alles gut.
Den Rest kann man googeln.
Richtig.
Und eine Adresse haben wir auch gleich.
Das passt schon auch.
Okay.
Super.
Ja.
Wir kriegen immer mal Rückmeldungen zu unserem DevOps-Podcast.
Die meisten beziehen sich auch immer auf den Einstieg in unseren Podcast.
Und was machen wir da, Luca und ich?
Wir bitten unsere Gäste immer um ihre persönliche Definition von DevOps.
Der Podcast geht natürlich über weitere Themen oder geht ein bisschen weiter als nur DevOps.
DevOps ist ja auch ein ziemlich weites Thema.
Aber Heiko, jetzt die Frage an dich.
Wie definierst du DevOps?
Jetzt muss ich also etwas sehr, sehr Schlaues oder sehr Originelles sagen.
Du hast es ja quasi gerade selber schon mal gesagt.
Ihr versteht darunter, das fand ich sehr spannend.
Du hast gesagt beides und hast dann aufgezählt kulturelle, organisatorische und technische Aspekte.
Also eigentlich drei Dimensionen sogar.
Dem würde ich mich gerne anschließen.
Was ich dazu sagen muss, als erstes dachte ich, als ich das erste Mal über DevOps gestolpert bin, dachte ich, wofür jetzt DevOps?
Weil ich halt Scrum kennengelernt habe und Scrum für mich eben auch Ops mit bedeutet.
Zumindest die Verantwortung dafür, auch Operations mit zu betreiben im Scrum Team.
Und deswegen dachte ich, wieso braucht es jetzt nochmal ein extra Label?
Aber naja, die Realität ist halt anders.
Also viele Teams verstehen sich tatsächlich rein als Entwicklungsteams und Ops gibt es dann halt irgendwo nochmal später.
Und da gibt es eine Übergabe.
Und deswegen dachte ich.
Deswegen dachte ich, eigentlich braucht es gar nicht sowas wie DevOps.
Inzwischen verstehe ich, dass es da nochmal einen extra Begriff für braucht, um es nochmal klarer zu machen, dass die Verantwortung eben zusammengehört.
Dass es keinen Sinn macht, nur an die Entwicklung zu denken und die zu machen und dann irgendwann an Ops zu übergeben.
Das hatte ich eigentlich als selbstverständlich hingenommen.
Aber ist anscheinend auch im agilen Kontext nicht ganz selbstverständlich.
Ich würde gerne noch einen Aspekt dazu bringen, worüber ich in letzter Zeit sehr häufig sprach.
Und das ist das, was ich immer wieder stolper ist, dass DevOps als Rolle definiert wird.
Wir haben jetzt einen DevOpsler im Team.
Darüber stolper ich jedes Mal und weiß nicht so richtig, was damit anzufangen ist, was soll.
Ja, also da würde ich auch drüber stolpern, wenn auch in Stellenanzeigen oder Angeboten für Freiberufler, wenn ein DevOps gesucht wird.
Ich habe auch schon mal auf so einer Anzeige mich gemeldet und gesagt, ob sie einen halben DevOps suchen, ob es den Pfundweise gibt oder so.
Die Frage kam nicht wirklich gut an auf der Gegenseite.
Aber ja gut, wer weiß, vielleicht kann man da nachher nochmal drüber reden.
Also da würde ich dir zustimmen.
Also das klingt komisch.
Aber gut, lass uns mal über das Thema sprechen.
Ich habe gesagt, das klingt im ersten Moment nicht wirklich spannend.
Die Gesetze der Zusammenarbeit.
Also du hast eine Sammlung erstellt der Gesetze zur Zusammenarbeit.
Diese Liste dazu hast du auf deiner Webseite www.bartblog.de.
Für alle die, die jetzt schon nebenbei ein bisschen beim Zuhören googeln wollen.
Also insofern vielleicht als Einstieg.
Was ist diese Liste?
Was siehst du unter einer Sammlung von Gesetzen zur Zusammenarbeit?
Es ist irgendwann in den letzten Jahren standen, bin ich irgendwie drüber gestolpert, dass ich auf Wikipedia auf eine tolle Übersichtsseite zu diesen kognitiven Verzerrungen oder Biases gestolpert bin.
Schöne Zusammensetzung.
Gibt auch ein tolles Bild dazu.
Und ich dachte, warum gibt es sowas nicht für, also ein paar Sachen kenne ich halt.
Die nennen sich alle dann Gesetze.
Parkinson’s Law, Ashby’s Law, Dunbar’s.
Zahl ist das dann, glaube ich.
Aber Conway’s Law habt ihr euch ja mit Sicherheit auf diesem Podcast schon mal mit beschäftigt.
Peter-Prinzip, Moore’s Law und so weiter und so fort.
Es gibt viele Sachen, wo quasi Law dahinter steht.
Also im Englischen oder eben Parkinson’s Gesetz.
Also quasi eine Gesetzmäßigkeit, ein Phänomen, was beobachtet wurde und wo dann irgendein schlauer Kopf gesagt hat, das ist wie eine Art Naturgesetz.
Also jetzt nicht wie ein menschlich gemachtes Gesetz, sondern wie eine Art Naturgesetz, was man halt im sozialen Miteinander und bei der Arbeit beobachten kann.
Und irgendwie, also ich habe gesucht, gesucht, gesucht.
Und ich habe keine Übersichtsseite dazu gefunden.
Und da ich jetzt kein Wikipedia-Insider bin, habe ich jetzt eben nicht versucht, irgendwie eine Wikipedia-Seite aufzumachen und da so eine Übersichtsseite zusammenzutragen, sondern habe es halt in meinem eigenen Blog gemacht.
Habe erst mal einen Tweet losgelassen.
Ich glaube, da bist du auch das erste Mal drüber gestolpert und hast Input gegeben.
Ich habe genau diese Frage gestellt und habe da ganz viel Input gekriegt.
Dann hat es ein paar Monate gedauert.
Und dann habe ich daraus tatsächlich diese Sammlung noch ein bisschen vervollständigt, noch ein bisschen weiter recherchiert und eben auf meiner Webseite im Blog veröffentlicht.
Einfach als, also es sind ja keine wirklichen Gesetze.
Es muss ja nicht so sein.
Da gibt es bestimmt auch Gesetze, die sich teilweise widersprechen, was ich auch ganz spannend finde.
Aber es sind alles Denkanstöße, wo man mal gucken kann.
Hey, tappen wir gerade in diese selbe Falle und was kann man da vielleicht gegen tun?
Oder wenn man jedes Mal gegen eine Wand läuft und denkt, wieso klappt denn das nicht?
Dann hilft einem vielleicht dabei, sich eines dieser Gesetze wie das Studenten-Syndrom vor Augen zu führen.
Und dann versteht man vielleicht die Mechanismen dahinter, warum das so passiert, wie es gerade passiert.
Ja, also ich nutze das, also eines der Parkinson-Gesetze immer auch als Einstieg in meine Scrum-Schulungen.
Das hast du bei dir auch geschrieben.
Arbeit dehnt sich genau in dem Maße aus, wie Zeit für ihre Erledigung zur Verfügung steht.
Dann sieht man schon das erste Mal das Schmunzeln, weil so geht es mir zumindest in den Scrum-Schulungen.
Da sitzen dann häufig Menschen drin, die vielleicht mal was davon gehört haben, aber eben eher vielleicht auch ein bisschen,
ich sage mal skeptisch eingestellt sind.
Und dann kommt schon mal so das erste zustimmende Lächeln.
Weil wenn ich mir das angucke, dieses Beispiel, was ich jetzt eben herausgewählt habe, das ist ja genau so etwas.
Das ist zwar ein bisschen ähnlich.
Ironisch gemeint, so habe ich das jedenfalls auch bei dir so gelesen.
Aber es ist zumindest ein Punkt, wo man sofort zustimmt, wenn man den gesunden Menschenverstand anschaltet.
Ach, so ironisch ist das, glaube ich, gar nicht gemeint.
Okay.
Also ich glaube, das lässt sich so beobachten.
Also ich glaube, ich bin jetzt nicht wirklich der Historiker.
Aber ich meine, er hat das eben seine Forschung darum, wie sich quasi Verwaltungen, Bürokratien entwickeln.
Und das ist halt ohne das, wenn eine neue Stelle geschaffen wird, dann wird sich diese neue Stelle Arbeit suchen.
Und sie wird nicht Däumchen drehen und sich langweilen, sondern sie wird die Zeit füllen mit etwas, was zu tun ist.
Und um es jetzt mal ganz krass zu sagen, während meines Studiums habe ich eines meiner Praktika, habe ich bei einem so einen Ein-Mann-Unternehmensberater gemacht.
Der wurde damals bei, immer gerufen, der hatte gute Connections zum Bertelsmann-Konzern.
Und wenn es da irgendwie eine, was aufzuräumen, in Anführungsstrichen, gab, also irgendwie nicht produktiv genug, nicht, bringt nicht genug Geld, dieser Unternehmensbereich, dann wurde unter anderem halt auch mal er gerufen.
Und ich durfte da ein Praktikum machen, ihn ein halbes, ich glaube ein Vierteljahr habe ich ihn begleitet.
Und er hat mir irgendwann mal gesagt, wenn er so gerufen wird.
Da eine Restrukturierung machen oder die müssen profitabler werden.
Seiner Erfahrung nach ein Unternehmen, wo er noch nicht war oder was schon lange nicht mehr von jemandem wie ihm unter die Lupe genommen wurde.
Ein Drittel der Belegschaft können wir streichen, können wir darauf verzichten.
Seine Aufgabe ist es jetzt, das richtige Drittel rauszufinden.
Und halt den politisch korrekten Weg zu finden, das halt so zu machen und sozialverträglichen Weg zu finden.
Aber genau, wohlwissend, Parkinsons Law, mit gutem Gewissen und Gewissen werden neue Stellen geschaffen, wird expandiert, aber das trägt nicht unbedingt immer zur Effizienz bei.
Also man kann locker auf ein Drittel verzichten und immer noch genauso gute Arbeit und die wichtigere Arbeit erledigen.
Das war zumindest seine Einstellung.
Das wollte ich nicht ganz so teilen, aber es deckt sich halt mit der Beobachtung von Parkinson.
Ja, ja, das ist richtig.
Gibt es noch ein paar andere Punkte, die du von Parkinson auch für die Praxis als relevant einschätzt, wo man eben mal schmunzeln oder nachdenken kann?
Also ehrlich gesagt benutze ich auch tatsächlich immer dieses Gesetz.
Weil sich das halt schön eben dann mit Studenten-Syndrom halt dazu führt, zu erklären, warum man eben im agilen Sinne Time-Boxing benutzt.
Also eben nicht sagt, okay, wir machen so lange, bis es fertig ist.
Sondern wir gucken mal, dass wir es in einem Sprint schaffen und wieder draufgucken, um eben diese Möglichkeit, dass sich die Arbeit immer weiter ausdehnt und ein Fass ohne Boden wird, um das eben zu beschneiden.
Einfach zu schauen, okay, lass uns immer wieder draufgucken.
Das heißt ja nicht, wenn wir nicht fertig geworden sind, dann sind wir halt nicht fertig geworden.
Aber wenn wir uns ein halbes Jahr Zeit nehmen, dann werden wir halt auch ein halbes Jahr dafür brauchen, statt zwei Wochen.
Wir werden nicht Däumchen drehen, sondern es fallen uns goldene Wasserhähne und Sahne.
E-Tüpfelchen ein, die wir noch oben draufsetzen.
Dadurch versuchen wir das halt zu umgehen, indem wir uns nicht so viel Zeit geben, um uns auf das Wesentliche zu fokussieren.
Deswegen ist das das Gesetz, was ich da benutze.
Ja, also ich finde das auch mal sehr schön.
Da kommt bei mir häufig der Hinweis, ja wieso?
Aber wenn wir noch nicht fertig sind, können wir doch nicht aufhören mit der Arbeit.
Und dann sind wir sofort in den Diskussionen drin.
Was ist fertig?
Also was sollte man sich da vorher überlegen, wann etwas fertig ist und eben einsteigen in die Definition.
Das ist essentiell, ja.
Aber jetzt, wo du mich gefragt hast, wenn ich da reingucke, Ausgaben steigen stets bis an die Grenzen des Einkommens, finde ich auch super, ja.
Ja, stimmt.
Danke.
Ja, also du hast ja auf dem Blogbeitrag eine ganz, ganz lange Liste zusammengestellt.
Da gehen wir jetzt mal so ein bisschen durch.
Du hast ja auch schon gesagt.
Converse-Law werden wir sicherlich behandelt haben.
Ich sage ja, definitiv.
Wir haben auch das Buch Team Topologies, was du ja auch so begeistert gelesen hast, wie ich, wenn ich das so richtig aus dem Gespräch auch mitbekommen habe.
Das geht ja auch da ein bisschen weiter.
Also insofern Converse-Law müssen wir uns nicht anschauen.
Ich finde noch ganz interessant, was für mich nämlich neu war, als ich da reingeschaut habe.
Demmings, ja, 8515 Regel.
Also die hatte ich irgendwann mal gehört.
Aber weiß nicht.
Was kann man dazu sagen?
Wo ist diese Demmings-Regel in der Praxis denn aufzufinden oder anzuwenden?
Die ist tatsächlich auch jetzt erst noch im Nachgang dazugekommen.
Ich weiß gar nicht, wo ich die aufgeschnappt habe.
Aus irgendeiner LinkedIn-Diskussion, glaube ich.
Und die klingt erst mal so wie eine Abwandlung des Pareto-Prinzips, aber eben für einen ganz bestimmten Fall.
Also Pareto-Prinzip ist klar.
Irgendwie so mit 20 Prozent des Aufwandes schafft man 80 Prozent der Ergebnisse.
Demmings, 8515 Rule sagt, ich lese es jetzt einfach mal vor, oder ich versuche es zu übersetzen, wenn ich es vorlese.
Weil dazu habe ich keine gute deutsche Quelle gefunden, dass 85 Prozent der Effektivität der Mitarbeitenden im Unternehmen durch das System vorherbestimmt wird.
Und maximal 15 Prozent durch die Skills und Fähigkeiten der einzelnen Mitarbeiter.
Also da geht es darum, die Systemtheoretiker, die systemischen Coaches werden jetzt alle mit dem Kopf nicken und sagen, ja, es geht darum, sich das Gesamtsystem anzugucken.
Und jetzt nicht zu sagen, der Mitarbeiter da, der performt nicht.
Das wäre eben ein rumkrittelnder Mensch und auch ein sehr fragwürdiges Mensch.
Aber selbst wenn wir das mal außen vor lassen, dann sagt diese Regel, die Demming dort beobachtet hat und aufgestellt hat, dass 85 Prozent wirklich durch System definiert wird.
Und wir sollten also lieber schauen, dass wir an den Strukturen, am System arbeiten, an dem Miteinander.
Wie gehen wir miteinander um? Wie kommunizieren wir miteinander?
Wie werden Entscheidungen getroffen? Und so weiter und so fort.
Und weniger.
Ich muss den mal aufhören.
Ich muss eine Schulung schicken oder ich muss mal dem ins Gebetsbuch reden, dass der sich mal ein bisschen mehr anstrengt oder was auch immer.
Oder noch schlimmer, über Boni und Mali zu sprechen für individuelle Leistungen.
Oder einen Coach zu rufen. Coach den mal, der muss besser werden.
Ja, das ist super.
Okay.
Ja.
Okay.
Fand ich auch sehr spannend.
Hatte ich vorher noch nicht gehört.
Also Demming kenne ich sonst nur plan, do, check, act.
Ja.
Ja.
Also auch da wieder für die, die jetzt zuhören, auch das ist etwas, wo du auch einen schönen Link hast auf eine andere Seite, wo das ein bisschen erklärt ist, wo auch, was ich eben auch immer schön finde, ist, wenn ich mit Demming dann einsteige, dass wir da eben Themen aus anderen Bereichen übernehmen und das quasi in die IT tragen.
Also hier reden wir über Qualitätsmanagement.
Also etwas, was überall wichtig ist und was man auch losgelöst von der IT betrachten kann.
Also insofern finde ich das auch interessant, dass wir auch hier aus anderen Bereichen, aus anderen Wissensgebieten Dinge quasi auch für uns in der IT übernehmen können.
Ja, total.
Ja.
Jetzt.
In dem Fall ist es übrigens mal kein Wikipedia-Artikel.
Und da der Aufruf gerne an deine Hörerinnen und Hörer, falls ihr erstens da drauf schaut und euch was fehlt.
Ja.
Dann gerne kommentieren beim Blogartikel und was drunter schreiben, was da vielleicht noch fehlen sollte.
Und falls ihr eine bessere Quelle findet als das, was ich jetzt irgendwie gefunden habe, dann natürlich auch sehr gerne.
Ja.
Stimmt.
Also insofern als Kommentar unter deinem Blogbeitrag, wenn jemand auch da noch eigene Erfahrungen einbauen kann oder berichten kann, kann man natürlich auch gerne dazu nochmal eine Podcast-Folge machen.
Also wer meint, er hätte zu einem Thema noch mehr zu erzählen, außer Conway.
Das haben wir jetzt schon abgefrühstückt.
Der darf sich gerne melden und darf natürlich dann gerne auch Dinge ergänzen.
Da können wir auch eine Folge draus machen.
Okay.
Also ich habe ja, oder wir sprechen ja gerade über deine Liste, über die Gesetze der Zusammenarbeit.
Wir haben ja auch gesagt, die Gesetze sind jetzt keine juristischen Gesetze, keine menschlichen Gesetze.
Wir reden über Gesetzmäßigkeiten, die beobachtet wurden.
Und wenn man jetzt so ein bisschen auch auf das Thema DevOps schaut.
Was ich interessant fand, was du auch beschrieben hast von der Nielsen Norman Group.
Why you only need to test with five users.
Also wie bist du darauf gekommen und was kann uns das helfen?
Das ist ja quasi fast wieder nochmal dasselbe, nur auf etwas anderes bezogen.
Also auch so eine Art Pareto.
Also die haben herausgefunden, ich bin darüber gestolpert in dem Buch Sprint.
Also was den Design Sprint von Google Ventures beschreibt.
Also in fünf Tagen von einer konkreten Produktidee zu einem validierten Prototypen.
Und da, wie soll das gehen?
Mit umfassender Marktforschung funktioniert ja gar nicht.
Und da ist halt ein Aspekt, über den ich gestolpert bin, dass halt diese Nielsen Group,
ich weiß nicht, ob ich es 100% richtig wiedergebe, dass sie eben mal irgendwann auf die Idee gekommen sind, sich anzuschauen,
wie viele tausend Kundeninterviews oder Nutzerinterviews haben wir geführt.
Und dann haben sie sich angeschaut, okay und jetzt mal rein qualitativ.
Also was wir sagen, nach wie vielen Interviews haben wir wie viel Prozent der möglichen Probleme, Bedürfnisse eines Nutzers herausgefunden.
Und sie sind halt darauf gekommen, das nagel mich jetzt nicht 100% darauf fest,
dass nach fünf Interviews 80 oder 90% der Probleme in den Interviews schon genannt wurden.
Jedes weitere Interview kann dazu dienen, quasi das nochmal zu untermauern,
aber es kommen wahrscheinlich relativ mit einer geringen Wahrscheinlichkeit noch neue Probleme,
neue Bedürfnisse dazu, die ich neu entdecke.
Also eigentlich nach fünf qualitativen Interviews kann ich anfangen,
in die quantitative Marktforschung zu kommen.
Wenn ich das machen möchte, wenn ich da eben schon in der Phase bin, dass sich das lohnt.
Aber um überhaupt herauszufinden, welches Problem will ich lösen und gibt es das Problem überhaupt und ist das Problem wichtig,
reichen fünf Interviews.
Das ist verrückt, oder?
Ja, aber es ist verrückt, aber dann doch wiederum irgendwie nachvollziehbar,
weil du hast es ja selber gesagt, wir reden ja immer über 80, 20, 85, 50, was auch immer.
Also im Prinzip.
Letzten Endes nicht den Anspruch, sozusagen 100% mit einem, also mit einem Aufwand X zu erreichen,
sondern eben auch schrittweise vorzugehen, mit kleineren Schritten im Prinzip genauso gute Ergebnisse zu liefern oder zu bekommen.
Ja, zumindest statistisch gesehen halt ganz gute Abdeckung zu haben
oder mit einer hohen Wahrscheinlichkeit das Wichtigste herausgefunden zu haben, ja.
Ja.
Ich blätter gerade noch ein bisschen.
Ich habe gedacht, wir haben jetzt so 20 Minuten hinter uns.
Lass uns mal über soziales Faulenzen sprechen.
Da gibt es so einige Sachen, die so in eine ähnliche Richtung gehen.
Ich muss das mal kurz suchen.
Die Liste ist tatsächlich schon relativ lang geworden.
Wo ist die denn?
Ist relativ weit oben, oder?
Ja, so Anfang des zweiten Drittels.
Okay.
Also sobald Individuen im Kollektiv mit anderen auf ein gemeinsames Ziel hinarbeiten und dabei ihre Einzelleistung nicht bekannt wird,
reduziert sich die psychologische Anspannung und sie fangen an.
Das ist so dieses Phänomen, Team steht für Tolle, ein anderer macht es.
Wenn ich weiß, naja, vielleicht ist ja noch jemand anders da, dann kann ich mich unter Umständen eben auch darauf ausruhen.
Tja.
Ja, naja.
Also ich habe bei deinem Tweet, habe ich den Ringelmann-Effekt ergänzt.
Der sagt ja im Prinzip etwas Ähnliches.
Der ist weiter unten.
Also auch das ist ja bei Wikipedia beschrieben, dass da eben auch, das ist sogar auch, ich wollte nicht sagen wissenschaftlich bewiesen.
Also das wäre jetzt übertrieben, wenn ich sage, es ist wissenschaftlich bewiesen.
Aber da ist ja auch jemand, der das sozusagen zumindest mal ein bisschen versucht hat nachzuweisen.
Also Ringelmann-Effekt ist genauso, dass man eben sagt, dass Menschen in der Gruppe eine geringere kollektive physische Leistung erbringen.
Ja.
Und das ist auch vielleicht der wichtige Punkt, weil ich denke, dir geht es wie mir.
Ich bin jemand, der für Teams steht, der glaubt, dass Teams eine bessere Organisationsgestaltung bedeuten oder eine effektivere.
Wenn ich natürlich physische Leistungen nur habe, dann passt es vielleicht doch nicht so von der Begrifflichkeit her.
Ja.
Um nochmal auf das Faulenzen hinzukommen.
Da steht ja auch, dass es ein Kollektiv mit anderen auf ein gemeinsames Ziel hinarbeiten.
Und wenn die Einzelleistung nicht bekannt ist, okay, ich würde das vielleicht ein bisschen anders formulieren.
Aber tatsächlich, wenn ich als Team arbeite und keine Transparenz habe, also wenn ich tatsächlich die Möglichkeit gebe, dass sich einer versteckt und irgendwie so tut, als würde er arbeiten und die anderen für sich arbeiten lässt.
Ja, da kann ich mir vorstellen, dass es vielleicht den einen oder anderen gibt, der sowieso denkt, blödes Team, blödes Ziel, da habe ich eigentlich gar keine Lust drauf.
Und dann nutze ich eben diese Möglichkeit aus.
Ja.
Deswegen.
Und das ist aus meiner Sicht eben auch sehr, sehr wichtig.
Und irgendwo findet sich das, glaube ich, auch nochmal wieder bei den fünf Disfunktionen eines Teams.
Für Transparenz zu sorgen, immer wieder an dem Miteinander im Team zu arbeiten und es eben nicht zu ermöglichen, dass sich jemand versteckt.
Ja.
Ich will jetzt nicht sagen, sozialen Druck zu ermöglichen, sondern dazu muss ich ja gar nicht kommen.
Aber das bräuchte ich dann, wenn Faulenzen überhaupt schon quasi sich etabliert hat.
Und wenn ich weiß, ach, der dreht ja auch nur Däumchen, dann mache ich das auch.
Das ist dann ja auch so ein…
Ach, da gibt es, glaube ich, auch einen Effekt, der hier beschrieben ist, den ich jetzt gerade nicht genau weiß, wie der heißt.
So ein Carpenter-Effekt.
Wenn der eine das tut, dann hat das auch wiederum Auswirkungen auf die anderen und die haben das nach.
Das ist halt auch soziologisch erforscht, dass das dann passiert.
Ja.
Ich habe auch gedacht, hoffentlich sagt er jetzt nicht nachweisbar.
Es ist ja erforscht, weil das sind ja immer nur Experimente.
Man kann das ja, denke ich, in dem Sinne nicht statistisch nachvollziehbar nachweisen.
Aber ich glaube, jeder von uns kennt auch solche Leute, die sozial faulenzen oder wo man zumindest den Eindruck hat, dass die sozial faulenzen oder gefaulenzt haben.
Und wenn ich jetzt das mal so ein bisschen vergleiche, auch mit der Historie, vielleicht mit einer klassischen Organisation,
dann sehe ich aber schon in einer Teamorganisation den Vorteil, dass dieser Druck oder diese Nachfrage, tust du was, wie auch immer man sie formuliert,
dass das, glaube ich, besser ankommt und effektiver ist, wenn das die Teammitglieder fragen, als wenn es der Chef sagt oder der Chef fragt.
Ich glaube, auch viele Führungskräfte wissen, wen sie in ihrem Team haben, wer in diese Richtung vielleicht ein bisschen geht.
Aber ich glaube, wenn das die Kollegen oder Kolleginnen ansprechen und sagen,
auf ihre Art und Weise, Mensch, ich habe den Eindruck, dass und so, dass das erstmal handfester passt
und dass man dann, wenn man eine gute Gesprächskultur hat, da auch eher dran kommt, da ein bisschen gegenzuarbeiten.
Und ehrlich gesagt ist ja soziales Faulenzen auch als Individuum nicht unbedingt anstrebenswert.
Also ich selber habe mir, also ich laufe und ich habe mir irgendwann gewöhnt, ich muss morgens laufen,
weil abends dauert es dann vielleicht doch mal ein Meeting länger.
Also muss ich morgens laufen, bevor irgendwelche Workshops.
Oder so losgehen.
Aber ich bin eigentlich kein Morgenmensch.
Also ich drehe mich gerne auch nochmal um und sage dem Wecker, dass er mich fünf Minuten später nochmal wecken soll.
Oder wenn es regnet, dann bleibe ich lieber liegen.
Und um das zu vermeiden, was ja quasi Faulenzen ist, habe ich mir einen Trainingspartner mit dem organisiert.
Und wir haben uns halt morgens um sechs verabredet, uns zum Laufen zu treffen.
Und ich weiß, wenn der da steht, dann lasse ich den da nicht warten.
Und dadurch habe ich für mich das Faulenzen zum sozialen Faulenzen gemacht und damit vermieden,
weil ich eben das dann eben Transparenz gemacht habe und gesagt habe,
naja, nein, so kann ich mich selbst durch meinen Trainingspartner dazu zwingen,
dass ich wirklich aufstehen muss und das machen muss.
Weil ich habe mich ja immer schlecht gefühlt, wenn ich dann liegen geblieben bin.
Ich glaube, das wird…
Also wenn ich dein Partner wäre, das würde ich zweimal mitmachen.
Genau.
Dass ich dann da stehe und du bist nicht da.
Genau.
Also ich habe quasi dieses Phänomen selbst ausgenutzt, um mich dazu zu zwingen,
quasi in diese Routine reinzukommen, wirklich laufen zu gehen.
Ja.
Deswegen ist das Faulenzen jetzt nicht unbedingt so gemeint, dass alle Menschen das anstreben sollen.
Das passiert halt vielleicht.
Ja.
Und das findet dann diejenigen, die es machen, finden es vielleicht auch gar nicht gut,
also fühlen sich vielleicht auch nicht mal gut damit.
Ja.
Langeweile ist, glaube ich, das Schlimmste, was einem passieren kann im Job.
Ach ja, das sagst du, das sage ich.
Gucken wir uns vielleicht nochmal was anderes an.
Weil direkt daneben steht Social Facilitation oder soziale Erleichterung besagt,
dass Lebewesen bei bloßer Anwesenheit von Artgenossen mit einfachen Aufgaben bessere Resultate erzeugen.
Mhm.
Witzigerweise, bei komplexen Aufgaben kehrt diese Erleichterung um und die Leistung der Person sinkt.
Ah, okay. Also auch das ist hilfreich für die Praxis, sich das mal zu überlegen.
Wie kriege ich komplexe, also wie geht, dann sollte Mob-Programming eigentlich nicht funktionieren.
Also nicht so gut, als wenn wir einzeln sind.
Passt natürlich ein Stück weit in, vielleicht ist dann Ashby’s Law einfach,
dann doch noch wichtiger, was ja auch mit in dieser Liste ist,
dass das einfach schwerer wiegt, als eben die Social Facilitation.
Dass dann doch die Schwammintelligenz, wenn wir eben eine ganze Gruppe an einem Thema arbeiten lassen,
also eine sehr komplexe Aufgabe, dann auch wenn vielleicht die einzelne Leistung einer einzelnen Person sinkt,
ist dann trotzdem die Gesamt, wie ist das doch immer so schön,
ist dann mehr als die Summe der einzelnen Teile, ist das dann halt doch Mehrwert über Ashby’s Law.
Mhm.
Das ist eben der Effekt der Social Facilitation.
Ja.
Aber vielleicht gab es zu dem Zeitpunkt, als sie das untersucht haben, eben auch noch gar nicht so was wie Mob-Programming,
was sie vielleicht hätten testen können.
Ich finde auch, das habe ich vorhin auch gesagt, das ist ja, du hast ja gesagt, das sind Gesetzmäßigkeiten.
Also man kann das vielleicht irgendwie sozusagen, nee, nicht nachweisen, man kann das nachvollziehen,
man kann das durch ein paar Experimente aufs Trapez bringen,
aber es gibt so viele Dinge, die man in diesen Experimenten dann nicht mit drin hat.
Also ich denke, dass zum Beispiel auch die kulturelle Umgebung eine Bedeutung hat.
Also dass diese Gesetze oder die Gesetzmäßigkeiten dann vielleicht nicht in jedem Kulturkreis gleich wirken.
Das wird ja ausgeklammert.
Also das ist zum Beispiel ein Punkt.
Insofern sehe ich auch diese ganzen Gesetzmäßigkeiten und unser Gespräch heute als Initiative, als Inspiration,
darüber mal nachzudenken.
Und sich auszutauschen.
Du hast gesagt, wir wollen uns ein paar andere Sachen angucken.
Das ist ja wirklich eine mordsmäßig lange Liste.
Die Miller’sche Zahl, die finde ich auch nochmal besprechenswert.
Genau, die kennt wahrscheinlich jeder irgendwie.
Schon mal drüber gestolpert, wie groß sollte ein Team sein?
Da trifft man halt immer drauf.
Scrum sagt ja auch, sieben plus minus zwei oder zumindest in früheren Versionen des Scrum Guides.
Aber dass es darauf beruht, dass eben ein Mensch gleichzeitig eben nur genau so viele Informationseinheiten im Kurzzeitgedächtnis präsent halten kann,
hat ich glaube ich auch schon mal gehört, war mir aber gar nicht mehr so bewusst, dass das von daher kommt.
Und dass deswegen eben auch, naja, wenn wir jetzt nochmal an typische Strukturen denken, ein Chef mit seinem Team, wenn er mehr als zehn Leute hat,
dann passen die halt nicht mehr ins sein Kurzzeitgedächtnis.
Das wäre dann schon nicht so schlecht, wenn ich zumindest mein gesamtes Team im Kurzzeitgedächtnis noch behalten könnte.
Deswegen macht das total Sinn, eben dort vielleicht in eine Zellteilung zu denken.
Oder wir müssen ja nicht an Chefs denken, wir können ja auch an Product Owner mit seinem Team denken oder Scrum Master mit seinem Team oder ihrem Team.
Und die Größe des Kurzzeitgedächtnisses, das ist genetisch festgelegt.
Das heißt, kann man auch durch Training nicht steigern.
Ja.
Weil ich könnte mir vorstellen, dass mindestens einer der Zuhörer, also ich meine jetzt keinen Konkreten, dass der aber sagt,
Mensch, ich kann das, also ich schaffe das.
Also es geht für die anderen, aber nicht für mich.
Sehr schön.
Ich weiß, dass ein Zuhörer jetzt wahrscheinlich lächelt.
Der hat nämlich ein Team in seinem Bereich mit 20 Leuten.
Und das hat er schon ziemlich lange.
Und ich sage schon ziemlich lange, das sind zu viele.
Also, liebe Grüße.
Jetzt habe ich hier auch die…
Den Beweis, dass das zu viele sind.
Zumindest einen wissenschaftlichen Hinweis.
Ja, wobei, ich weiß gar nicht, ob das da nochmal weitergeht.
Ist das bei Danvers Zahl?
Egal.
Also irgendwo…
Stimmt.
Da bin ich mir gar nicht sicher.
Irgendwo muss es noch etwas geben.
Eine soziale Forschung.
Also zumindest erzähle ich das immer.
Da gibt es bestimmt einen stehenden Begriff dazu, der mir jetzt gerade nicht einfällt und der noch nicht in dieser Liste ist.
Das heißt, genau ab dieser Zahl, oder vielleicht hängt es auch mit Millersche zusammen.
Weil es geht ja nicht nur um Chef und sein Team, sondern auch ich in meinem Team, mit meinen Teammates, mit denen ich die ganze Zeit zusammenarbeite.
Wenn ich da 20 habe, ich habe aber immer nur maximal neun in meinem Kurzzeitgedächtnis.
Also werde ich eine stärkere Bindung, eine stärkere Zusammenarbeit mit einem Teil dieses Teams aufbauen.
Und das führt dann dazu, dass eben…
Und da kommen eben auch noch Kommunikations…
Wenn man sich anguckt, wie die Kommunikationskanäle innerhalb des Teams, wie das eben exponentiell wächst, wenn einfach die Teilnehmendenanzahl steigt.
Dass dadurch Teams von 20 Leuten automatisch in Subteams zerfallen.
Aber vielleicht nicht in solche Subteams, wie wir sie vielleicht…
aus agiler Sicht gerne hätten, nämlich in cross-funktionaler Sicht.
Sondern dann glucken sich eben vielleicht die Tester zusammen und die Designer zusammen und die Entwickler zusammen.
Und schon haben wir eine Art Wasserfall innerhalb eines Teams.
Was wir so eigentlich vermeiden wollten.
Ja, richtig.
Die Silos, die wir dann doch in der agilen Welt haben dann, die sich irgendwie doch irgendwie ergeben.
Ja.
Du hast eben noch eine andere Zahl angesprochen.
Die Dunbar-Zahl oder Dunbars Number.
Das finde ich eben auch sehr, sehr interessant.
Vielleicht für die, die diese noch nicht kennen.
Das ist eine Zahl, die die Anzahl der Personen beschreibt, von denen jemand die Namen und die wesentlichen Beziehungen untereinander kennen kann.
Also das ist eine Zahl, auf die hast du eben schon ein bisschen abgehoben.
Die liegt so oder die soll so bei 150 liegen.
Und auch da wiederum, was ich interessant finde, das ist etwas, was nicht aus der IT kommt, sondern aus anderen Bereichen.
Das ist eben von einem Psychologen entdeckt oder entwickelt worden.
Triffst du da auch in deiner Praxis auf Bestätigung dieser Zahl oder wie wichtig ist diese Zahl für die Praxis?
Da kann ich nur an meine eigene Erfahrung denken.
Als ich Angestellter war, bin ich in das Unternehmen reingekommen.
Da waren wir, glaube ich, zu zwanzigst.
Als ich gegangen bin, waren wir so um die 200.
Inzwischen ist die Firma, glaube ich, so bei 400.
Und ja, diese 100 war tatsächlich so ein Punkt, wo in den Gesprächen, wenn man so auf Firmen-Events zusammengekommen ist, wo es dann langsam losging, dass Leute gesagt haben, oh, ich kenne gar nicht mehr alle.
Ja.
Das war tatsächlich so rund um die 100.
Also ja, habe ich gelesen, da ist jemand Neues gekommen.
Aber bis 100 habe ich schon nochmal irgendwie jemanden, jeden gekannt und auch auf einem Firmen-Event mal mitgesprochen und so weiter.
Da, ab dieser Zahl hat es dann angefangen, dass man auch darüber reflektiert hat und festgestellt hat in den Gesprächen.
Huch, wer ist das denn eigentlich?
Ne, kenne ich auch nicht.
Ja, doch, das ist die und die und so weiter und so fort.
Also das hat es bis dahin nicht so schön geklappt.
Das hat bis dahin nicht so stattgefunden.
Das ist jetzt für Scrum-Teams gar nicht so wichtig, glaube ich.
Naja, man könnte sich überlegen, was sagt Les?
Irgendwie acht Teams könnte man zusammenführen, dann sind wir ungefähr noch knapp unter der Konvei, unter der Dunbar-Grenze.
Vielleicht spiegelt sich das auch da wieder, dass ein Product Owner, ein Chief Product Owner dann mit bis zu acht Teams an einem Produkt arbeiten kann.
Ja.
Bevor man dann wieder in die nächste Komplexitätsskalierung gehen muss.
Ja, also ich denke auch, dass sich diese Zahl in Safe auch wiederfindet und dass dann Menschen oder Gruppen, die solche Frameworks entwickeln, natürlich schon aus ihrer praktischen Erfahrung was einbauen, aber eben auch sich auf solche Gesetzmäßigkeiten beziehen.
Klar.
Gut.
Wir kennen alle in dem agilen Umfeld den Cargo-Kult.
Und das, finde ich, ist auch nochmal interessant.
Warum taucht der Cargo-Kult in deiner Liste auf?
Ja, ich weiß, da steht jetzt nicht Gesetz drauf, aber ich habe es nicht ganz so wichtig, nicht ganz so eng genommen.
Auch das ist ja quasi eine Gesetzmäßigkeit.
Alles, was ich nicht kenne und nicht genau verstehe, kann ich halt missdeuten und denken, naja, wenn ich jetzt ein Kanban-Board an die Wand hänge oder Jira einführe, dann wären wir jetzt agil.
Das kann ein Cargo-Kult sein.
Ist das nicht so?
Also ich kenne Firmen, die sagen, wir sind agil, wir nutzen Jira.
Ja, genau.
Okay.
Ja.
Ich glaube, da gab es noch eins, was dann in die Richtung ging.
Irgendwie hatte ich gerade noch eine Idee, aber wenn ich drauf komme, komme ich noch drauf.
Dann schmeiße ich noch ein.
Richtig.
Und ansonsten wollen wir auch die Leute ermuntern, auf deinem Blog ein bisschen zu lesen und ein bisschen zu stöbern.
Genau.
Ich merke, ich muss auf jeden Fall noch mal ein bisschen an der Sortierung arbeiten, aber das ist halt auch schon wieder so viel geworden, dass es schwierig wird, da eine echte gut zusammenhängende Sortierung hinzukriegen, weil die Zusammenhänge natürlich auch wiederum komplex sind.
Mehrere Sachen hängen ja mit anderen Sachen wiederum zusammen und so eine komplett eindeutige Sortierung wird es wahrscheinlich gar nicht geben.
Ja.
Ich finde auch toll den Dunning-Krüger-Effekt.
Ja gut, Krüger, ich habe es ein bisschen deutsch ausgesprochen.
Wenn ich mich an Twitter-Diskussionen beteilige, es wird ja weniger, dann komme ich aber häufig mit dem Hinweis, schau mal bei Dunning-Krüger nach.
Ich weiß, wie ich Dunning-Krüger erkläre, aber ich weiß, dass das auch ein bisschen, na ja, ich sage mal, ein bisschen überheblich klingen kann.
Also, was sagst du?
Wie würdest du den Dunning-Krüger-Effekt bezeichnen oder beschreiben?
Ja.
Ich lese es einfach vor.
Der Dunning-Krüger-Effekt bezeichnet die kognitive Verzerrung im Selbstverständnis inkompetenter Menschen, das eigene Wissen und Können zu überschätzen.
Das heißt, je weniger ich weiß, desto weniger weiß ich, was ich alles nicht weiß.
Also, je mehr ich weiß, desto mehr weiß ich, was ich nicht weiß und desto mehr bin ich mir vielleicht auch dessen bewusst, dass es da eben noch blinde Flecken gibt.
Wenn ich aber nur wenig davon weiß, dann habe ich vielleicht auch einfach nicht den Überblick, um eben das zu verstehen.
Ja.
Ich habe auch nicht den Überblick, um eben herauszufinden, dass es da noch Zusammenhänge gibt, die ich gar nicht so genau abschätzen kann.
Also, wenn ich da in mich rein denke, ja, wenn ich von einem Thema immer mehr verstehe, dann fängt es an, irgendwann kompliziert und komplex zu werden.
Aber am Anfang sieht noch alles, au, da ist die Lernkurve halt sehr, sehr schnell.
Da taucht man in ein Thema ein und lernt sehr, sehr, also ist die Lernkurve sehr, sehr steil.
Man lernt sehr viel und überschätzt sich dann vielleicht und denkt, hey, ich habe die Weisheit ja schon mit Löffeln gefangen.
Ja.
Aber dann, siehe Pareto, dann die letzten 20 Prozent Wissen herauszufinden, das ist dann halt der Marathon, den man dann noch zu laufen hat.
Ja, mit 20 Prozent Aufwand hat man vielleicht auch schon 80 Prozent.
Da fehlt dann halt die Demut in der Twitter-Diskussion, sich das halt dann auch zuzugestehen, dass man eben vielleicht erstmal noch nicht bei 90, sondern erstmal nur bei 75 Prozent ist.
Ja, na ja.
Wobei wir ja in Deutschland oder zumindest, wenn ich auf Deutschland blicke, den beneidenswerten Part haben, dass wir über 80 Millionen Bundestrainer haben, dass wir über 80 Millionen Virologen haben und die Liste ließe sich unendlich fortführen.
Jetzt Ironie-Modus Ende.
Also deswegen, da fällt mir das immer entsprechend ein.
Und wie gesagt, meine Erklärung ist ein bisschen mit anderen Worten.
Aber lass uns ein bisschen wissenschaftlich und abgehoben bleiben.
Also ich lese auch in dem Wikipedia-Beitrag, dass das schon von Sokrates beschrieben wurde.
Ich weiß, dass ich nichts weiß.
Das ist ja auch ein wichtiger Punkt, den man dann letzten Endes auch nutzen sollte, wenn man sich dieses Effektes bewusst ist, eben nicht aufzuhören, etwas zu lernen und immer wieder, wie du sagtest, mit einer gewissen Demut oder einem gewissen, ich sag mal, Abstand zu dem eigenen Wissen vorwärts zu gehen.
Ein kleiner Hinweis noch an der Stelle.
Das ist eine, steht ja auch in dem Text, den ich vorgelesen habe, das ist eine kognitive Verzerrung.
Also eine dieser Biases, die beschrieben sind.
Dazu gibt es wiederum eine Wikipedia-Übersichtsseite und tolle Charts, die das auch visualisieren, einen Überblick geben.
Das habe ich auch verlinkt.
Ich habe jetzt diesen Effekt mit reingenommen.
Ich habe jetzt aber nicht vor, alle Effekte, alle kognitiven Verzerrungen hier mit reinzubringen.
Aber den fand ich jetzt wiederum so passend für das Thema Zusammenarbeit, dass ich den hier gerne mit aufgenommen habe.
Sehr schön, ja.
Ich habe noch ein anderes Gesetz bei dir in der Liste gefunden, das ich jetzt gerne nochmal ansprechen würde, weil es so ein bisschen, ich sag mal, in Richtung Technik geht.
Und DevOps ist ja auch Technik.
Das Moore’sche Gesetz.
Ich dachte, du wolltest Murphy jetzt bringen, aber nein.
Okay, Moore.
Ach so.
Murphy ist doch der mit dem Marmeladenbrot.
Also insofern hat das ja nichts mit Technik zu tun.
Kann ja auch passieren, dass wenn man einen Podcast aufnehmen will, dass dann das Mikrofon genau in dem Moment den Geist aufgibt.
Also auch da ist Murphy auch immer mal gerne mit von der Partie.
Moore’sches Gesetz.
Ja, genau.
Du bist der Techniker oder bist näher an der Technik.
Das hat ja auch nichts mit Technik zu tun, es besagt halt, dass die, mit meinen Worten, als Laie ausgedrückt, dass die Rechenkapazität sich alle 12, 18, 24 Monate verdoppelt.
Und deswegen…
Ne, ich meine, das sehen wir ja was, tatsächlich, wenn man zurückguckt, was damals so ein C64 ist und was wir heute für eine Rechenkapazität und unseren Smartphones haben.
Ich weiß nicht, wie viele C64s in unserem Smartphone drin stecken, aber auf jeden Fall einige.
Ja, ja, ja. Und da sei auch dann die, also man kommt dann ja von deiner Liste auf die Wikipedia-Seite und da sind schon ein paar schöne Grafiken auch, die das wirklich nochmal belegen oder darstellen, wie sich das wirklich, dass man es wirklich herleiten kann, dass man es wirklich beweisen kann und jetzt vielleicht doch wirklich beweisen kann.
Gut. Gibt es ein paar Gesetze, ein paar Themen, die du ansprechen wolltest, die dir jetzt gerade in unserer Diskussion hier gefehlt haben?
Ich gucke gerade mal. Über eins bin ich gestolpert. Das fand ich so schön wegen des Namens. Ich suche ihn gerade mal. Das ist der Dr. Michael J. Fox-Effekt, die durch ein Experiment validierte Hypothese lautete, dass ein gut repräsentierter Vortrag selbst erfahrenen Zuhörern,
also Experten,
die im Publikum sitzen, das Gefühl vermitteln kann, etwas gelernt zu haben, auch wenn der Vortragende totalen Quatsch erzählt hat. Also sie haben dann quasi Michael J. Fox auf die Bühne gestellt, der von dem Thema keine Ahnung hatte, auch tatsächlich Quatsch erzählt hat. Im Publikum saßen Experten und die haben sich einfach davon beeindrucken lassen, dass das eben ein Experte anscheinend irgendwie da oben ist, der das erzählt und der es gut vorgetragen hat und haben hinterher,
ausgesagt, dass sie, ja, dass das alles Hand und Fuß hatte und dass sie etwas Neues dazugelernt haben. Das ist verrückt. Das haben wir ja vielleicht auch bei einigen publikumswirksamen Politikern in den letzten Jahren gesehen, wo ich es zwar nicht nachvollziehen kann, also für mich machen die jetzt nicht den Eindruck eines gut präsentierten Vortrags, aber auf manche halt irgendwie schon.
Ja, ja.
Okay. Ja, stimmt. Also finde ich auch interessant, dass ich habe, als ich das bei dir gelesen habe, dachte, hey, Michael Fox war doch gar nicht Doktor. Also, ja.
Und da habe ich mir Mühe gegeben, die Reihenfolge so passend hinzukriegen, weil darunter steht, der Sleeper-Effekt kommt aus der Sozialpsychologie und ist ein Phänomen zwischenmenschlicher Kommunikation, bedeutet zum Beispiel, dass die Effektivität der Inhalte von einem
sehr glaubwürdigen Sprecher mit der Zeit ab und jene eines unglaubwürdigen Kommunikators zunimmt. Nach vier Wochen hat die Effektivität der beiden Mitteilungen von glaubwürdigen und unglaubwürdigen Sender angeglichen.
Könnte man sagen, ist ja vielleicht ganz gut, dass dann eben, also der Michael-Jay-Fox-Effekt nimmt dann mit der Zeit ab. Also irgendwann lässt man sich dann nicht mehr davon beeindrucken, sondern nimmt dann vielleicht auch jemanden, der rhetorisch nicht so gut aufgestellt ist.
Dann wird das, was der sagt, dann wiederum als glaubwürdiger auch angenommen. Das gleicht sich irgendwie an.
Ja, stimmt. Das passt natürlich zusammen. Gut. Ich habe ja gesagt, dass wir ein interessantes Gespräch haben werden, dass wir hoffentlich ein paar Inspirationen geben konnten. Wie gesagt, bartlog.de auf deiner Blog-Seite oder auf dem Bereich Blog-Gesetze der Zusammenarbeit.
Denn wenn ich das richtig einschätze, dann glaube ich…
…kriegen wir bei Spotify die Shownotes nicht rüber. Also Spotify kennt, glaube ich, keine Shownotes. Und wir sonst ja immer sagen, ja, schreiben wir in die Shownotes, machen wir jetzt auch, kommt in die Shownotes rein. Aber für die, die es da nicht finden, bartlog.de, Blog und dann Gesetze der Zusammenarbeit.
Wer sich jetzt animiert fühlt, da nochmal ein bisschen durchzuscrollen, so wie wir es jetzt auch gemacht haben und wo wir auch so darüber gesprochen haben. Wir haben jetzt so gefühlt, ich sag mal, wir haben ein Drittel angesprochen, oder?
Ich glaube noch nicht mal. Ich glaube noch nicht mal.
Ja.
Aber ich hatte noch einen Aufruf an die Hörerinnen und Hörer.
Sofort. Gerne.
Und zwar einfach kommentieren. Also Nadja hatte kommentiert und da bin ich auf die Idee gekommen, also weil sie schrieb, das könnte man im nächsten Team-Workshop irgendwie benutzen. Und da dachte ich, huch, wie denn? Will man sich da die Liste angucken?
Aber man könnte eben das tatsächlich irgendwie ausdrucken, auf Kärtchen machen und dann per Zufallsprinzip in der Retro im Team-Workshop.
Mal darüber diskutieren und sagen, hey, was ist das für ein, also in kleinen Gruppen mal und sehen wir dieses Phänomen bei uns? Also haben wir das schon mal beobachtet und ist das gut für uns oder ist das nicht gut für uns?
Also wer das mal ausprobieren möchte, fände ich super. Danach dann mal dann zu sagen, zu schreiben oder sich an dich zu wenden oder an mich so direkt zu wenden, sehr gerne, was dabei rausgekommen ist, ob das geklappt hat, ob das ein gutes Workshop-Format ist.
Oder wer noch auf andere Ideen kommt, wie man diese Liste nutzen kann, weil ich habe erst mal nur die Liste gemacht, ohne Gedanken, was man damit jetzt tatsächlich machen könnte.
Ja, es ist so.
Auch der längste Weg beginnt mit dem ersten Schritt. So, genug klug geschissen hier.
Vielleicht noch dann der letzte Werbehinweis, wo man dich ja auch treffen kann, glaube ich, so habe ich es gelesen, beim PM-Camp in Berlin, 17. und 18.
September. Das heißt, wer dich kennenlernen möchte, kann auch nach Berlin fahren, oder?
Jein, also wir werden es auch dieses Jahr nochmal online stattfinden lassen. Also wir müssen nicht nach Berlin fahren. Nächstes Jahr, so die Pandemie will, wird es dann das zehnte Jubiläums-PM-Camp Berlin geben und das soll dann auch wieder im Real Life stattfinden.
Dieses Jahr gerne noch auf dem Sofa sitzen bleiben und einfach online teilnehmen.
Kostet nicht viel.
Kostet nicht viel und alle Einnahmen gehen an guten Zweck. Also insofern sehr gerne.
Cool. Das freut mich, weil, also es freut mich nicht, dass die Pandemie da ist und Leute auf dem Sofa sitzen bleiben sollen, aber jetzt beim neunten PM-Camp, wo ich auch welligt hatte hinzukommen, kann ich nicht, weil ich im Urlaub bin, aber vielleicht kann ich das dann für das zehnte PM-Camp einrichten und dann vor allen Dingen wirklich wieder physisch, dass man sich wirklich einfach mal in die Augen gucken kann.
Und so weiter. All diese vielen, vielen schönen Vorteile von physischer Präsenz und von physischen Kongressen.
Ja. Wobei, wir haben letztes Jahr tatsächlich einige Stimmen gehört, die gesagt haben, boah, das war noch besser als physisch.
Ja, also, naja, jetzt kommen wir natürlich auf ein Thema, was ist besser oder so. Also ich glaube auch da, es gibt nicht besser oder schlechter, es gibt nur passt oder passt nicht.
Genau, deswegen, individuell war das so das Zitat und deswegen habe ich es jetzt so zitiert.
Ich würde es auch nicht so sagen, es ist anders, ja, aber es gibt wie immer auch gute und schlechte Real Life und gute und schlechte Online-Formate.
Ja, und vielleicht ist das auch so ein kleines Schlusswort oder gibt es irgendwas aus deiner Sicht, was du jetzt noch so ergänzen würdest mit Rückblick auf diesen Podcast?
Es waren ja immerhin knapp 50 Minuten. So eine kleine Zusammenfassung oder haben wir alles gesagt, was für dich wichtig war?
Ich glaube, das war super. Ich habe mir tatsächlich noch eine Sache aufgeschrieben, die passt jetzt vielleicht sogar auch dazu, weil ich bin auch die letzten Tage darüber gestolpert, dass bei jedem Handover, also wenn jemand etwas an jemand anders übergibt, womit wir wieder bei dem Thema DevOps wären, dass eben kein Handover stattfinden muss von DevOps zu Ops, sondern dass wir das in einem Team haben, in einer Verantwortung,
dass jeweils 50% bei jeder Übergabe 50%.
Prozent der Informationen oder des Wissens
verloren geht. Und deswegen freue ich mich,
dass wir direkt miteinander gesprochen
haben, Dirk, und
dass wir hier keinen Handover hatten und
irgendwie noch jeden Mittelsmann
mit dem wir Spielepost gespielt haben, sondern
dass wir einfach direkt miteinander geredet
haben. Vielen Dank für die Einladung.
Gerne. Vielen Dank für dein
Auftritt, nein, für deine
Gesprächsbereitschaft, auch so kurzfristig.
Und dann würde ich sagen,
ich wünsche dir noch einen schönen
Resttag und
wer weiß, wann wir uns auch mal wiedersehen,
auch vielleicht mal in Projekten, auch bei der
Vibas. Vielen Dank auch von
meiner Seite aus und
schönes Wochenende für dich. Tito, danke.

Klicken Sie auf den unteren Button, um den Inhalt von podcasters.spotify.com zu laden.

Inhalt laden

In dieser Folge haben wir André Claassen zu Gast. Wir sprechen über OKR (Objectives & Key Results) und die Verbindung zu DevOps. Was sind OKRs und wie kann man sie im DevOps-Umfeld nutzen. Sind OKRs nur etwas für größere Unternehmen oder kann man sie auch in kleineren Organisationen oder sogar Start-Ups nutzen? Wofür werden OKRs überhaupt eingesetzt?

In dieser Episode diskutieren Luca Ingianni und Dierk Söllner zusammen mit dem Gast André Claassen die Schnittstelle zwischen DevOps und OKR und vertiefen sich darin, wie diese Rahmenwerke in der Praxis integriert werden können. Klaassen betont die Bedeutung von zielorientierter Planung und deren Einsatz zur Förderung organisatorischen und kulturellen Wandels. Er bietet Einblicke in die Messung von Ergebnissen statt Outputs und die Notwendigkeit, Strategien anzupassen, um einen agileren und effektiveren Ansatz für Projektmanagement und Softwareentwicklung zu fördern. Die Diskussion berührt auch Herausforderungen und Chancen bei der Anwendung von OKR im DevOps-Kontext.

Inhalt

• Einführung in den Schwerpunkt der Episode auf DevOps und OKR.
• André Claassens Hintergrund und Expertise in agiler Arbeit und Digitalisierung.
• Diskussion über Objectives and Key Results (OKR) und deren Integration in DevOps.
• Die Bedeutung kultureller, organisatorischer und technischer Aspekte bei der Implementierung von OKR in DevOps.
• Einblick in das Konzept der ergebnisorientierten Planung.
• Die Relevanz messbarer Schlüsselergebnisse und der Fokus auf Ergebnisse statt Outputs.
• Herausforderungen und Strategien bei der Anwendung von OKR in verschiedenen organisatorischen Kontexten.
• Empfohlene Ressourcen und Literatur für die weitere Erkundung von OKR und DevOps.

Shownotes:

Buchempfehlung: Outcome over Output von Josh Seiden
Präsentation Roadmaps are Dead
Podcast Ziele setzen, Ziele erreichen mit OKR
Webseite von André Claassen

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 Luca Injani und Dirk Söllner. Ich freue mich,
dass Luca heute dabei ist, denn er hat eigentlich aktuell Wichtigeres zu tun. Also
hallo Luca, freut mich, dass du zu Beginn und hoffentlich auch zu Ende dabei bist.
Ja, hallo ihr beiden.
Gut, was das Wichtigere ist, darf ich auch noch kurz erwähnen. Luca sitzt auf heißen
Kohlen, weil er so etwas wie einen Entbindungstermin hat. Also wie gesagt, freut mich, dass du
dabei bist. Luca und ich sind DevOps-Trainer und Coaches. Wir haben langjährige Erfahrung
und für uns ist der Punkt, DevOps immer, dass wir…
Kulturelle, organisatorische und technische Aspekte damit reinbringen. Heute reden wir
ein bisschen was über Kultur, über organisatorische Punkte eventuell auch. In dem Podcast diskutieren
wir das immer mit Experten aus der Praxis oder Luca oder ich auch gemeinsam in einer
Folge, wo wir uns einfach nur ein bisschen unterhalten. Aber heute haben wir einen Experten
aus der Praxis und mit dem werden wir uns hoffentlich auch gut unterhalten. Wir haben
heute das Thema DevOps und OKR. DevOps ist ja schon seit Jahren so ein Modewort, ein
Hype-Thema.
OKR kommt langsam auch in diese Regionen. Also insofern freuen wir uns, dass wir diese
beiden Themen zusammenbringen können. André Klaassen ist unser Gast. André war schon
mal vor zwei Jahren da bei uns zu Gast im Podcast. Insofern, André, würde ich sagen,
stell dich einfach mal ganz kurz vor. André Klaassen
Ja, mein Name ist André Klaassen. Ich freue mich, dass ich heute bei euch dabei sein darf.
Heute mit einem anderen Thema. Vor zwei Jahren haben wir, glaube ich, über das Thema agile
Arbeit im Allgemeinen gesprochen und Digitalisierung. André Klaassen, du hast ja auch schon gesagt,
du hast ja auch schon gesagt, du hast ja auch schon gesagt, du hast ja auch schon gesagt, du hast
gesagt, du hast noch PAR 찬 agreee’t und gesagt. Heute geht es um das
Thema Objectives and Key Results, was meine Passion geworden ist, oder als dahin zu sprechen.
Also ein Framework zur Zielvereinbarung und Umsetzung, auch im agilen Kontext. André
Klaassen
Ich selbst habe über 30 Jahre Erfahrung in Projektmanagement, IT-Projekten, aber
auch Organisationsberatung und Strategieentwicklung. Meine Heimatbranche war lange Zeit Public Sector,
öffentliche Verwaltung, aber ich bewege mich mittlerweile auch in ein Normales Projekt.
André Klaassen
Genau.
Let’s get into it, Herr irregular급àngなんか.
André Klaassen
In anderen Gefilden Mittelstand, Energiesektor und Automotive und freue mich sehr auf das heutige Gespräch, wo es sicher die eine oder andere Idee gibt, über die wir dann gerne reden können.
Sehr schön. Ja, und in dem Vorgespräch, in der Vorbereitung haben wir auch schon festgestellt, dass es ein Thema ist, was vielleicht noch gar nicht so viel Praxiserfahrung mitbringt, wo es auch vielleicht noch gar nicht so viel, sag ich mal, Literatur oder Blogbeiträge dazu gibt, wie zu anderen Themen.
Aber wenn man mal schaut, was du so alles schon mal zusammengetragen hast an Themen, dann glaube ich, wird uns nicht langweilig in dieser dreiviertel Stunde Stunde.
Und insofern, André, wir freuen uns.
Wir fangen bei unseren Gästen immer damit an, dass wir sie fragen, wie sie DevOps definieren würden.
Wir haben uns jetzt nicht die Mühe gemacht, zu gucken, wie du DevOps vor dem letzten Podcast definiert oder beschrieben hast, aber einfach nochmal frei raus, wie würdest du DevOps beschreiben?
Ja, ich bin ganz ehrlich, das ist ein Begriff, der sich für mich auch weiterentwickelt, wie auch das Thema agile Arbeit oder Objectives and Key Results.
Heute.
Würde ich sagen, also für mich ist der DevOps die Übersetzung der Prinzipien des Lean Management, also tatsächlich ein Stück weit aus dem Toyota Production System heraus in die Welt der IT.
Also die Idee ist, Wertschöpfung mit Kundennutzen zu generieren, einen Fluss an Lösungen zu etablieren in cross-funktionaler Arbeit.
Da sind Dev, also Developer Operations drin, für mich aber auch noch andere Experten.
Die notwendig sind, um den Wertefluss zu etablieren und um diesen Wertefluss auch gut umsetzen zu können, zählt auch das Thema Automatisierung rein.
Ich kann aber auch vielleicht sagen, was DevOps für mich nicht ist.
DevOps ist für mich nicht die meisterhafte Beherrschung von Integration Tools oder Kubernetes oder sonstigen Dingen.
Also, weil das habe ich oft festgestellt, dass in dem Kontext der technischen Automatisierung.
Das Thema sehr stark ist.
Ich sehe es genau wie du es gesagt hast, Dirk und Luca.
Es ist auch ein kulturelles Thema, weil ich brauche tatsächlich ein Stück weit eine andere Geisteshaltung, um DevOps richtig gut machen zu können.
So, jetzt habe ich sehr lange Monologen gesichert über DevOps.
Ist alles falsch oder was sagt ihr dazu?
Also ich sage ja immer, es gibt nicht falsch und es gibt nicht richtig, es gibt passend oder nicht passend.
Aber zum Thema Kultur und Technik, da hat Luca ja auch seine Meinung.
Ja, also ich sehe das nämlich ganz genau so.
Technologie ist an dieser Stelle halt nur ein Mittel zum Zweck.
Ja.
Und Kubernetes ist gut und schön, aber wenn du es nicht unterfütterst mit entsprechenden passenden Ansätzen, was Methoden angeht und so weiter,
dann hast du halt einfach nur ein neues Problem ans Bein gebunden, aber eigentlich nichts gelöst.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Okay.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Du kannst also bei OKRs tatsächlich, wenn du jetzt nur auf die Methode schaust, nur auf, vielleicht sogar auch nur auf Tools,
jetzt gibt das gar nicht so heiße sophisticated Tools, ja, sondern es sind am Ende reden wir hier über Performance Management Tools,
aber wenn du nur auf die Tool- und Methodenecke schaust, dann kann OKR ein Klotz am Bein werden.
Dann kann OKR ein Bürokratiemonster sogar.
werden, indem ich nämlich anfange, Ziele zu verwalten,
statt Ziele umzusetzen. Und
hier brauche ich, genau wie bei DevOps, einfach ein Stück weit eine andere
Kultur, ist übrigens auch das Thema, was ich mitgebracht habe,
nämlich das Denken in Wirkung. Was will ich denn wirklich
erzielen und was will ich denn wirklich bewirken mit meinen Lösungen?
Und diese
Geisteshaltung, tatsächlich ergebnisorientiert zu
denken, ich sage jetzt mal flapsig, das ist ja etwas, was man unserer Bundeskanzlerin
unterstellt, also von hinten zu denken, das hat
eine hohe Ernsthaftigkeit. Und da können
OKRs sehr helfen, aus meiner Sicht auch und gerade bei
DevOps. Aber wenn ich das nicht kultiviere, sondern nur
meine klassischen Projekte,
meine Aufgaben, meine Outputs, meine Features, vielleicht auch meine Roadmaps einfach nur in Form
eines OKRs darstelle, ja, dann habe ich erstmal gar nichts gewonnen, sondern
vielleicht wäre sogar noch ein gutes Stück mehr Arbeit aufgeschafft. Aber sind wir
vielleicht schon sehr, sehr weit in dem Thema? Vielleicht sollten wir erstmal vorne anfangen.
Ja, ja, ist aber
ein kleiner Teaser, dass alle, ah, da kommt noch was und da,
okay. Also, du hast die Frage dir selbst gestellt. Lass uns
vorne anfangen. Was ist dieses OKR eigentlich?
Ja, OKR steht für Objectives and Key Results, also
Ziele und Schlüsselergebnisse. Und das scheint
ja auch erstmal sehr, sehr einleuchtend zu sein. Historisch ist es tatsächlich
eine Erweiterung des Management
by Objective and Self-Control, also ich wiederhole
and Self-Control von Peter Dracker. Peter Dracker,
Management-Papst der 60er, 70er,
und 80er Jahre, hat eben überlegt, wie kann ich
Wissensarbeit, die immer wichtiger wird und die einen immer größeren
Anteil an Arbeit umfasst, wie kann ich die besser organisieren?
Und eine Idee war, die hat er sogar ein Stück weit
von dem preußischen General
Herrn Moltke übernommen, zu sagen, eine
Idee ist es eigentlich, Aufgaben vom Ergebnis
her aus zu beschreiben, also den,
Ziel zu beschreiben, aber nicht zu viel Lösungen zu beschreiben.
Und diese Ziele gut vereinbart ermöglichen Self-Control,
also Selbstmanagement und Selbstorganisation.
Das war die ursprüngliche Idee von MBO.
Alles, was wir heute unter Performance Management und Zielvereinbarung sehen,
ist die methodische Ableitung, die aus meiner Sicht auch teilweise
überhaupt nichts mehr mit dem Planen dieser Idee zu tun hat.
Und daraus wurde ein objektives,
ein Key Result auf eine sehr pragmatische Weise.
Das hat Andy Goof, ehemaliger Manager von Intel,
weiterentwickeln hat gesagt, er muss mal zu Andy Goof auch sagen,
Manager des Jahres, weiß ich nicht, 1996.
Also wirklich sehr erfolgreicher Manager, aber von Natur aus Chemiker,
also pragmatischer Naturwissenschaftler, hat gesagt Egal, was wir hier bei Intel tun,
ich brauche einfach irgendwie ein Kriterium, woran ich erkenne,
sind die Dinge fertig oder nicht?
Also wirklich jetzt mal ganz basal.
Und er hat dieses Thema OKR dann kultiviert bei Intel und hat gesagt,
es geht überhaupt nicht darum, ob ihr Ziele verfehlt oder erreicht.
Es geht einfach nur darum, dass wir wissen, wo wir gerade stehen und mit welchem Tempo
wir gerade unterwegs sind.
Und er hat die Idee von Peter Dracker, also das Management by Objectives in Self-Control
aufgegriffen, hat es zu OKRs weiterentwickelt.
Und das war einfach so die Form des Berichtswesens bei Intel, aber auch in Form von Transparenz.
Das heißt also, diese Ziele, diese Objectives und die messbaren Schlüsselergebnisse,
die waren tatsächlich in dem Unternehmen überall präsent und die konnte auch jeder einsehen.
Wichtig ist halt das Thema, also das betonte Andy Groove auch immer wieder,
es ist keine Performance Management, es ist keine Leistungsüberwachung von Teams oder
Personen, sondern es ist einfach nur ein Tool.
Um letztendlich Klarheit in der Sache zu schaffen.
Heute sind wir aber viel weiter und das OKR hat sich weiterentwickelt.
Es ist auch ein offenes System.
Es gibt also keine Firma oder Institution, die definiert, was OKR macht.
Ich glaube, das ist ein bisschen ähnlich wie bei DevOps, wo es meines Wissens auch
keine Firma gibt, die da die Hand drauf hat.
Und OKR ist halt insofern ein offenes Framework und dient heute.
Im Jahr 2018.
Ja.
Und ich glaube, das ist auch ein offenes System, das wir in den nächsten Jahren,
im Jahr 2021, dazu Strategien umzusetzen und zwar auf agile Art.
Die Idee ist, ich setze mir in einer Kadenz, beispielsweise in drei Monatsintervallen,
das können aber auch andere Widmen sein, Wirkungsziele.
Das heißt, ich überlege mir, was möchte ich in drei Monaten fokussiert an Wirkung
bewegen?
Wo ist der große Hebel in meinem Business?
Wo ist der große Kundennutzen, den ich heben möchte?
Und daraus entwickle ich ein sehr kleines, knackiges OKR-Set, aus meiner Sicht maximal
drei Ziele, vielleicht sogar nur ein Ziel, den großen Hebel, und den beschreibe ich
dann in Objectives & Key Results.
Gleich nochmal zu den Key Results, Messschlüsselergebnisse.
Hier geht es darum, tatsächlich Messbarkeit darzustellen, also ein Key Result ohne Zahl
ist kein Key Result.
Das ist platt dahergesagt.
Aber das ist ein Key Result.
Aber das ist tatsächlich sehr, sehr wichtig, weil ich auch in meiner Praxis ganz oft feststelle,
dass das ein Punkt ist, wo tatsächlich ein Stück weit Übung erforderlich ist.
Ja, also viele Aufgaben sind entweder erledigt oder nicht, und das ist eigentlich kein gutes
Key Result.
Gleich möchte ich, wenn ihr mich lasst, aber das werden wir dann sehen, auf das Thema Outcome
zu sprechen kommen, weil das ist aus meiner Sicht das kleine Geheimnis hinter OKR.
Okay.
Aber nicht.
Darf ich kurz dazwischengrätschen?
Ja.
Weil nämlich, also bevor ich dich über Outcomes reden lasse, würde ich mir wahnsinnig wünschen,
dass du das vielleicht noch ein bisschen konkreter machst, wie so ein OKR aussieht.
Ich bin mir nicht sicher, ob unsere Hörer sich das wirklich gut vorstellen können.
Was ist denn das?
Ist das ein Projektantrag?
Ja, es ist erstmal, es ist kein Projektantrag, sondern OKR ist ein Ziel, das ich mir in einem
Team oder in einer Organisation vorstelle.
Das OKR hat aus meiner Sicht jetzt nicht die Absicht, alle Themenfelder, die es gibt,
jetzt abzudecken, sondern eigentlich den Hebel zu finden, also die Fokussierung auf bestimmte
Themen, die wir in einem Quartal erzielen wollen.
Jetzt ist es natürlich nicht ganz so einfach.
Jetzt generische OKRs zu nennen, ich nenne mal jetzt, weiß ich nicht, ein Beispiel aus
meiner eigenen Praxis.
Ich bin ja auch Solopreneur, also selbstständig, aber letztendlich auch Einzelunternehmer und
ich mache diesen, mache regelmäßig Podcasts, um Sichtbarkeit und Expertentum einfach auch
darzustellen.
Ja.
Und.
Das zahlt ein Stück weit möglicherweise hoffentlich auch auf das Business ein, dass
also Leute mich ansprechen und sagen, hey, André, wir haben auch Interesse an Zielsystemen,
kannst du uns unterstützen?
Das Outcome, also die langfristige Wirkung, die ich eigentlich erzielen möchte, ist,
dass ich Kundeninteresse wecke und auch Sichtbarkeit erziele.
Um das zu tun, könnte ich jetzt als OKR beispielsweise formulieren.
Ich möchte.
Ich möchte meine Sichtbarkeit, meine Expertise erhöhen und ein Ziel in diesem Jahr wäre
es, weiß ich nicht, fünf Podcastgespräche durchzuführen.
Ja, weil wenn ich diese Gespräche durchgeführt habe, dann habe ich eine Wirkung erzielt oder
oder einen Indikator dafür erzielt, dass ich halt sichtbarer bin.
Aber ich merke gerade so richtig gut ist das Beispiel auch nicht.
Vielleicht nehme ich mal ein anderes Beispiel aus dem.
Aus dem Supermarkt.
Aus dem Support und lege auch mal so ein bisschen die wichtigsten Kernbegriffe auseinander.
Im Support könnte es sein, dass wir sagen Hey, wir müssen mal im Support Kosten sparen.
Ja, wir haben irgendwie zu viele Support Gespräche im Support.
Das Thema Kosten sparen oder das Reduzieren von Support Gesprächen, das ist etwas, das
bezeichne ich als langfristige Wirkung.
Auf Englisch Impact.
Also die langfristige Wirkung ist eigentlich die, die ich haben möchte, dass ich möglichst
wenig Support mache.
Ich sage sogar mal extrem, am schönsten wäre es, man müsste überhaupt keinen Support
machen.
Stimmt.
Also ich habe ein Produkt, das ist so wartungsfrei und so selbsterklärend und so robust und
so trivial, dass das Telefon gar nicht klingelt und dass das Ticketsystem verweist, ja, ist
eine Utopie.
Ja.
Aber eine Wirkung, die ich tatsächlich langfristig erreichen könnte.
Ich könnte sogar eine Mission daraus abbilden und sagen, unsere Mission ist es, unsere Produkte
so klar, einfach und wartungsarm zu machen, dass wir keine Support Anfragen bekommen.
Jetzt haben wir aber in der Praxis festgestellt, doch, wir haben natürlich eine ganze Menge
Support Anfragen.
Die Support Anfragen drehen sich um fünf Schlüsselthemen, die immer und immer und immer wieder benannt
werden.
Und diese fünf Schlüsselthemen sind im Produkt.
Das sind Produktprobleme.
Ein Outcome wäre jetzt zu sagen, auch im Sinne eines OKRs, wir möchten diese fünf
Produktprobleme lösen.
Ja.
Und wir messen das dadurch, dass wir nicht nur diese fünf Produktprobleme angepackt
haben, sondern wir messen das dadurch, dass wir, und das ist die Wirkung, die wir erzielen
wollen, die Anfragen zu diesen fünf Themenfeldern von X auf Y zurückgehen.
Das wäre das Key Result, das wir wirklich haben wollen.
Die Anzahl der Support Anfragen für diese fünf Produktthemen gehen von X, also heute
1000 pro Monat auf, weiß ich nicht, 500 pro Monat zurück.
Das ist die Wirkung.
Der Frühindikator, also die Metrik, die wir selbst in der Hand haben und die uns eine
Indikation darüber gibt, dass wir das auch wirklich erreichen, ist, tatsächlich diese
fünf Produktprobleme zu lösen.
Das wäre das Frühindikator.
Und das zweite Key Result, wir lösen die fünf Produktprobleme.
Auch das möchten wir in diesem OKR formulieren.
Und dann könnte man vielleicht nochmal ein drittes Key Result reinnehmen mit Kundenwirkung,
dass wir zu diesen fünf gelösten Kundenproblemen nochmal ein qualifiziertes Kundenfeedback
einholen, um einfach zu schauen, ob wir hier eine nachhaltige Wirkung erzielt haben.
Und das wäre ein Thema, Fokussierung auf ein Themenfeld, Überlegung, was ist das, was
ist die nachhaltige Wirkung, die wir erreichen wollen?
Messbar.
Das wäre Key Result eins, Überlegung, was können wir selbst tun, von dem wir glauben,
dass es diese nachhaltige Wirkung befeuert?
Key Result zwei und vielleicht nochmal ein Key Result drei, um das Ganze abzurunden aus
Sicht der Kundensicht.
Also das wäre so etwas, was ich als gutes OKR bezeichnen würde.
Okay.
Ich finde das ja super als Beispiel, weil das mir wirklich das nochmal klar macht und
weil für mich dabei auch rauskommt, diese Ergebnisorientierung, das, was du eben genannt
hast, wenn man da so eine Arbeitsgruppe bilden würde oder wie auch immer man das nennt, dann
würde man ja, würden die meisten ja sofort überlegen, was können wir machen, um das
zu erreichen?
Also man denkt dann sofort in den, in den Maßnahmen, anstatt zu beginnen, was sind
wirklich die Themen, die uns bewegen?
Also wo wollen wir nachhaltig eben Ergebnisse erzielen?
Okay.
Und das wirklich eben von hinten nach vorne das Pferd aufzuzäunen.
Sehr schön.
Und das ist eben gar nicht so einfach, wie sich das anhört und auch nicht einfach
auszuhalten.
Wenn ich über Ergebnisse rede, die ich erzielen will und das wichtigste Ergebnis ist die Reduktion
der Support-Anfragen.
Das ist eigentlich das, was richtig spannend ist.
Die fünf Produktprobleme ist, die ich lösen möchte, also dieser Frühindikator ist eine
Hypothese.
Es kann sein, dass ich nach Beleuchtung des Problems herausstelle, das ist eigentlich ein
ganz anderes Problem.
Wir haben immer gedacht, das sind die fünf Produktprobleme.
Quatsch.
Da war nun Readme falsch.
Ja.
Die Punkte sind wunderbar gelöst.
Es ist nur ein oder zwei Fehler drin gewesen in der Produktbeschreibung.
Ja.
So.
Das heißt also, diese Fokussierung auf die Wirkung, das ist eigentlich die Schlüsselmetrik.
Wir wollen die Support-Aufwände runterkriegen.
Und Ihr Team überlegt euch jetzt.
Ja.
Ja.
Was wäre aus eurer Sicht die beste Maßnahme, um dieses Delta zu erzielen?
Das ist halt spannend, da hinzukommen und das zu erarbeiten.
Die Formulierung lösbarer, aber interessanter Probleme, die einen Nutzen fürs Business
haben.
Mhm.
Und wenn ich das jetzt mal mit meinen Erfahrungen aus der Praxis vergleiche, wie ich OKR wahrnehme,
dann ist das auch ein Unterschied für mich.
Und das kann man ja auch gleich nochmal erklären.
Für mich ist OKR häufig auch in der Anwendung, dass man das nutzt, um Unternehmensziele, die
man erreichen möchte, quasi runterzubrechen auf Bereichsziele, auf Mitarbeiterziele, also
wirklich von oben nach unten Ziele runterzubrechen.
Ja.
Was ja erstmal, finde ich, sehr, sehr plausibel ist.
Was ja auch dazu führen würde, dass sich die Unternehmensleitung wirklich Ziele überlegt,
die sie erreichen wollen.
Und in der Regel, wenn man dann die Ziele, die sie erreichen wollen, dann muss man ja
erreichen wollen und in Ergebnissen denkt und dann versucht, zu gucken, wer, in welchem
Bereich kann man das, mit welchen Mitarbeitern, mit welchem Wissen erreichen.
Aber eben im Unterschied zu deinem Beispiel, quasi ein System, was ich auf ein gesamtes
Unternehmen ausdehne, wie ist denn da so, was ist denn da richtig sozusagen?
Also, ich kann OKR sehr, sehr gut nutzen, um Unternehmensstrategien umzusetzen.
Ja.
Es ist aber in dieser Zielkaskade, die du beschreibst, die auch sehr, sehr häufig gemacht
wird und die auch für viele Unternehmen erstmal der einfachste Weg ist in Richtung OKR, ein
Stück weit das Problem, dass wir dann sehr stark auf die Aufbauorganisation gucken.
Ja.
Das heißt also, es geht tatsächlich genau in der Aufbauorganisation runter.
Die meisten spannenden Stellen.
Probleme oder Herausforderungen bei Unternehmen sind aber eher in der Ablauforganisation zu
finden, als im Wertestrom.
Und daher ist es spannend, auch bei der Nutzung von OKRs eine Kultur zu etablieren, die darauf
abzielt, die Aufbauorganisation ein Stück weit zu ignorieren, um das mal beispielhaft
zu machen.
Ja.
Ich habe jetzt als Unternehmensziel.
Ja.
Ich nenne das jetzt, weil es ist ja kein schönes Ziel, Kosten zu sparen, ist eigentlich kein
gutes OKR, aber angenommen, es ist wirklich jetzt ein Thema, wir müssen jetzt Kosten
sparen, ist jetzt wirklich kein gutes OKR, dann ist dieses Ziel nicht gut operationalisierbar
in den unterschiedlichen Bereichen.
Was aber cool wäre, wäre, wenn wir sagen, okay, wir haben alle erkannt, das ist wirklich
gut, das ist jetzt nicht nur irgendwie eine Plattitüde, sondern wir müssen das tun, ja,
dass wir dann auf der Ebene der Unternehmensleitung und vielleicht auch zwei Ebenen darunter gemeinsam
überlegen, was können wir jetzt tun, um dieses Ziel maximal zu befeuern, auch vor dem
Hintergrund der Mitarbeiter, auf dem Hintergrund der langfristigen Ziele und lasst uns Ideen
entwickeln.
Das heißt, ich ignoriere bewusst mal dieses.
Ja.
Nicht nur das jetzt mal an die Bereiche und die geben das an die Abteilung weiter, sondern
wir überlegen gemeinsam mit der Intelligenz des Unternehmens, was können wir denn jetzt
tun, um das tatsächlich zu tun, was wären die wirksamsten Hebel und sinnvollsten Hebel,
um das zu tun.
Und deshalb finde ich es auch bei einer Unternehmenshierarchie, sogar auch bei Konzernen sehr, sehr spannend,
auch nicht in die Bereiche zu gehen, also der, weiß ich nicht, der Vorstand beschließt
ein OKR und das gibt ihr dann an die Bereiche, sondern ein Team zu bilden, das dann gemeinsam
überlegt, okay, was können wir denn jetzt wirklich auch auf dieser Ebene tun, um das
jetzt konkret umzusetzen und was, und da bin ich jetzt auch bei den Key Results, was sind
Dinge, bei denen wir selbst wirksam erkennen können, dass wir Fortschritt machen in dem
Thema.
Ja.
Wir kommen weiter und es tut uns gut und das sind andere Lösungen.
So, und dann funktioniert das auch auf der Unternehmensebene gut, wichtig ist, ich habe
keine Inflation an Zielen, sondern ich habe tatsächlich Fokussiele, ich habe, ich benutze
OKR, um die Hebel in Bewegung zu setzen, die jetzt aktuell am meisten drücken und am stärksten
auf die langfristigen Ziele einsetzen, das ist also wichtig, das zu finden.
Ja, weiß nicht, wie ich mir das überlege, weil du sagst jetzt, wir ignorieren die Auffahrorganisationen,
das ist für mich der Punkt, weil du vorhin sagtest, das ist eigentlich ganz einfach beschrieben,
aber schwierig umzusetzen, weil das hört sich jetzt so wunderschön im Podcast an und
ist auch sicherlich eine gute Idee, aber ich denke, man kann ja, oder es wird schwierig,
Realitäten, nämlich da ist eine Auffahrorganisation, die kann man ja insofern nicht ignorieren,
aber als Ziel.
Als Gedankenexperiment und auch als Prämisse finde ich das schon ein sehr schöner Ansatz
und das ist das, was ich jetzt hier heute schon gelernt habe, das ist letzten Endes
genau, also man kann das nutzen, wie du auch gesagt hast, aber man sollte auch mal über
den Tellerrand blicken und eben zum Beispiel auch sagen, wir gehen jetzt nicht in einer
klassischen Aufbauorganisationshierarchie runter, sondern wir haben irgendwelche Themen,
die wir erreichen wollen, übergreifend und wir setzen dann ein, ich nenne es mal OKR-Team,
das kannst du vielleicht gleich nochmal ein bisschen diskutieren.
Wir setzen ein OKR-Team zusammen und sagen, wie kriegen wir dieses Ziel erreicht?
Ja, es hängt von der Unternehmensgröße ab, das ist ganz klar.
Wenn ich ein Großkonzern habe, dann ist das, was ich sage, möglicherweise auch nicht sinnvoll.
Ich muss dann schon in Bereichen denken, weil die einfach auch unterschiedliche Rollen haben,
aber die Botschaft, die ich loswerden will, ist, das Design der Unternehmensziele mit
so zu denken, dass ich bei der Gestaltung auch ein Stück weit die Intelligenz habe,
die ich in der Unternehmensgröße habe.
Dass ich die Intelligenz des erweiterten Führungsteams nutze und die Intelligenz auch von Experten,
die helfen können, dass ich das einfach noch benutze, jetzt mal ein Stück weit.
Hier ist übrigens Indy Goof, Manager von Intel, ganz hilfreich, weil er sagte, Führungskräfte
sind in meinem Verständnis natürlich die Manager der Aufbauorganisation plus die Fachexperten
in den verschiedenen Units.
Er sagt, ich kann auf diese Experten aufhören.
Ich kann auf diese Expertise überhaupt nicht verzichten, wenn ich strategische Entscheidungen,
die intelligent sind, entwickeln werde.
Das heißt, für mich sind das genauso Führungskräfte im Sinne von Führung des Unternehmens in die
Zukunft.
Und was er damit sagen will, ist, Strategieentwicklung ist ein Stück weit auch Unternehmenssache,
wenn sie gut sein soll.
Das ist etwas, was Kollaboration erfolgt.
Die Umsetzung der Strategie.
Die ist natürlich dann immer auf den verschiedenen Ebenen durchzuführen.
Aber die große Entscheidung, da empfehle ich tatsächlich ein Stück weit mehr Kollaboration,
mehr Diversität, ein Stück weit auch Einladung von Subject-Meta-Experts, die also da auch
nochmal beitragen, wenn ich das OKR auf dieser Ebene gut designe und letztendlich auch mit
einer kollaborativen.
Aspekt gut designe, dann habe ich das in den wichtigsten Schritt geschafft.
Dann habe ich nämlich etwas geschafft, was Wirkung, Nutzen und auch Nachvollziehbarkeit
hat.
Und das ist dann mein Nordstern für die nächsten drei Monate im Unternehmen und den kann ich
dann auch aushalten.
Denn eins muss man wissen, bei dem Thema OKR auf Unternehmensebene reden wir eigentlich
immer über Strategieumsetzung und das größte Problem bei Strategien ist die Umsetzung.
Strategien kann jeder.
Aber ganz viele Unternehmen klagen auch, wir haben so eine tolle Strategie gemacht,
aber wir kommen nicht vorwärts.
Wir kommen nicht vorwärts.
Warum passiert das nicht?
Und das liegt einfach daran, dass die Wucht und Brutalität des Tagesgeschäfts jede Strategie
umhaut, wenn die nicht super klar, super plausibel und super fokussiert ist.
Die Strategie hat tatsächlich das Tagesgeschäft ein Stück weit umgesetzt.
Das ist eine sehr wichtige Sache.
Das ist eine sehr wichtige Sache.
Die Strategie hat tatsächlich das Tagesgeschäft ein Stück weit als Feind, ja, und braucht
eine gewisse Bestandskraft, Resilienz dagegen und die kriege ich nur hin, wenn die mit Sinn,
Verstand und vor allem mit einer maximalen Reduktion erarbeitet worden ist.
Das heißt also mit anderen Worten, wenn ich mehr als drei strategische Ziele habe, habe
ich schon kaum noch eine Chance, die zu erreichen, weil das einfach versetzt wird.
Ja, das fand ich auch interessant, weil du eben sagtest, Ziele, also Zielinflation, das
waren wirklich OKRs.
Ja.
Und das ist dann vielleicht so, wie ich jetzt nicht auch verstehe, einfach, ich sage mal,
punktuell einsetzt.
Punktuell einsetzt, weil bestimmten, natürlich bei den wichtigen Zielen und das nicht einfach
flächendeckend eben einsetzt, weil dann kommt man zu dem, was du eingangs sagtest, dann
habe ich wieder Verwaltung, dann habe ich Management, dann muss ich Tools pflegen, dann
habe ich viele Gespräche, um den Prozess zu unterstützen, um auch zu reporten, dass
ich den Prozess ja nicht blockiert habe.
Das heißt, so wie ich das bei dir verstehe, eigentlich eher so ein bisschen als Möglichkeit,
als, ich sage mal, leichtgewichtige Möglichkeit, Themen umzusetzen, sei es eine Strategie,
sei es andere wichtige Themen.
Ich muss dazu sagen, bei einer Strategieumsetzung gilt so ein Stück weit so die Faustregel,
je größer das Unternehmen ist, umso besser ist es, um so einen klaren Fokus zu haben
und wenige Ziele zu haben.
Bin ich ein Start-up, also bin ich mit fünf, sechs Leuten unterwegs, dann kann ich OKR
wunderbar dazu nutzen, die ganzen wilden Themen abzudecken.
Ja.
Weil ich habe eine superhohe Dynamik und ich brauche einfach Verbindlichkeit.
Das ist ein Problem bei Start-ups, dass wir einfach ein Stück weit mit Strukturfragen
kämpfen.
Das heißt, da würde ich OKRs vielleicht ein Stück weit anders nehmen und sagen, komm,
lass uns mal drei Monate klarziehen, was wollen wir insgesamt in den drei Monaten machen.
Bei einem Konzern, wo ganz viele Regel- und Standardprozesse da sind, da nutze ich OKRs
für den Hebel des Changes.
Da geht es um Veränderung.
Und zwar um den punktuellen, starken Hebel.
Und da würde ich tatsächlich mit wenigen OKRs arbeiten.
Okay.
Ja.
Und dann vertragen die sich übrigens wunderbar mit anderen Strategie-Umsätzen oder mit klassischen
Methoden wie einer Balanced Scorecard oder einem klassischen KPI-Berichtssystem, weil
ich dann nämlich sage, ich will gar nicht alles damit machen, sondern ich will an den
neuralgischen Punkten, an denen ich dramatisch besser werden will, da setze ich ein OKR drauf
und den Hebel draufzusetzen.
Mhm.
Das ist übrigens auch die Art und Weise, wie Google mit OKRs arbeitet.
Google ist ja so ein bisschen ein Posterschein, da muss man auch ein Stück weit kritisch
draufschauen.
Also Google ist das bekannteste Großunternehmen, das seit der Gründung kontinuierlich mit OKRs
arbeitet, aber auch kulturell das Thema immer weiterentwickelt hat.
Das heißt, die arbeiten heute mit OKRs ganz anders als noch vor 20 Jahren, aber für die
sind OKRs der große Hebel.
Ja.
Mhm.
Der Moonshot.
Genau.
Hier setzen wir einen Moonshot-Hebel drauf.
Hier wollen wir dramatisch besser werden.
Entschuldigung, wir scheinen wieder so ein bisschen lag zu haben.
Aber jetzt möchte ich gerade noch mal nachhaken, wie vertragen sich OKRs dann mit Tagesgeschäft?
Weil ich denke, es macht wenig Sinn, dass man sein Tagesgeschäft dann irgendwie in
einem Objective abbildet, oder?
Also wie gesagt, bei ganz kleinen Organisationen finde ich das richtig, aber wenn ich ein Start-up
bin, wo ganz viel Dynamik ist und ganz wenig situierte Prozesse, dann ist das nicht so richtig.
Ja.
Ja.
Ja.
Genau.
Ja.
Ja.
Die schnellen Prozesse würde ich die Dynamik tatsächlich in OKRs einfangen, einfach um
Struktur reinzubringen.
Habe ich aber ein Business, das stark durch Standards geprägt ist, ne?
Das könnten jetzt auch im Service-Management sein, beispielsweise.
Dann setze ich die OKRs auf das Thema Change und Improvement.
Das heißt also, dann kann ich die OKRs tatsächlich benutzen, um Wirkungsziele zu definieren,
die das Tagesgeschäft kontinuierlich besser machen.
Ja.
Zum Beispiel eine Möglichkeit oder eine strategische Veränderung, die im Unternehmen da ist, zu flankieren.
In so einem Setting benutze ich gerne ein sogenanntes OKR 0.
Das OKR 0 hat keine Key Results, also in Form von Schlüsselergebnissen, sondern bildet die wichtigsten KPIs des Tagesgeschäfts ab, die ich unter Kontrolle haben muss.
Also mehr oder weniger das Business, das ich gesund halten möchte.
Und den Change, also die Veränderung, die vielleicht auch Freiräume braucht, die auch ein bisschen Zeit braucht, das wäre dann mein OKR 1.
Und da habe ich meine Key Results drin für den Change.
Und möglicherweise sind da auch Key Results drin, die mir Luft verschaffen, im Tagesgeschäft diesen Change überhaupt durchzuführen.
Und so vertragen sich also OKRs.
Das heißt auch mit dem Tagesgeschäft, dass ich sage, ich habe einen Anteil an Standard und Prozessen, den möchte ich gesund halten, weil davon lebe ich und das muss gut funktionieren.
Da habe ich KPIs drauf, an denen ich erkenne, dass das Business gut läuft.
Und ich habe einen Change, der in der Regel eine Verbesserung, ein Improvement oder eine Veränderung darstellt.
Und das ist dann mein zweites OKR.
Vielleicht gibt es auch noch mein drittes.
Aber so würde ich, das ist so meine Empfehlung, Tagesgeschäft und OKRs zu verheiraten.
Man muss einfach schauen, wie viel Dynamik habe ich.
Bin ich jetzt in der Produktentwicklung, bin ich jetzt in der Innovation, bin ich jetzt in einem sehr dynamischen Umfeld,
dann helfen mir die OKRs genau diese Outcomes, die ich erzielen will, mit dem Team zu fassen.
Dann habe ich mehr OKRs.
Bin ich in einem sehr, sehr standardisierten, prozessualen, stabilen Umfeld,
dann haben die OKRs Zeit.
Tatsächlich einen kleineren Anteil.
Dann geht es einfach nur um Change von dem, also besser machen von dem, was wir ohnehin tun.
Vielleicht sind wir da schon ein bisschen bei DevOps.
Ja, wir haben noch gar nicht großartig über DevOps gesprochen, aber das kommt ja vielleicht gleich noch.
Du wolltest doch was zu Outcome sagen.
Ja, hinter diesem ganzen Thema OKR verwirkt sich, und das ist die Schule, die ich vertrete, das Outcome-Based Planning.
Also die Idee, dass ich…
Eine Planung nicht mehr auf Projektebene, Features und Arbeitsergebnisse durchführe, sondern auf Outcomes.
Hintergrund ist so ein bisschen meine Sicht auf das Thema Digitalisierung.
Dirk, du weißt, da habe ich mich auch so ein bisschen mit beschäftigt.
Das, was wir so gemeinhin als Digitalisierung bezeichnen, also auch die Vernetzung, gesellschaftliche Veränderung, Büroautomation,
ist ja ein Riesenpotpourri, und am Ende ist es ja auch ein Passwort,
ist für mich…
Aus meiner Sicht die Durchdringung unserer Welt mit Software.
Software hat immer größerer Anteil an der Wertschöpfung.
Das merkt zurzeit ganz stark die Automobilindustrie.
Denn das, was jetzt bevorsteht, ist nicht nur der Wechsel eines Antriebsstrangs,
sondern das ist die Veränderung der Intelligenz, der Automobilität insgesamt.
Und jedes Unternehmen ist aus meiner Sicht, und auch jede Behörde,
in irgendeiner Form im Software-Business.
Einige haben es noch nicht verstanden, viele merken es mittlerweile.
Wir sind alle irgendwo im Software-Business.
Und Software ist im Unterschied zu Fertigprodukten eigentlich nie fertig.
Sondern wir reden hier immer über Produkte, die immer besser werden.
Und um überhaupt Fortschritt zu erkennen, reicht es nicht mehr aus, einfach ins Backlog zu gucken
und zu schauen, wie viele Storys haben wir abgearbeitet,
sondern ich brauche…
Ich brauche ein anderes Maß.
Und das sind für mich die Outcomes.
Das ist das Maß, woran wir erkennen, ob wir Fortschritt in der Digitalisierung machen.
Die Wirkung, die wir erzielen.
Und jetzt kommt meine Sicht, was ist denn ein Outcome?
Ein Outcome ist die gewünschte Veränderung des Verhaltens von Menschen,
die meinem Business zuträglich ist.
Es geht um Menschen.
Und es geht um einen Schwerpunkt.
Es geht um einen Change, der dem Business zuträglich ist und der messbar ist.
Ich hatte eben das schöne Support-Beispiel genannt.
Ja, wir haben zu viele Sofort-Anfragen.
Das Verhalten, was ich verändern möchte, ist, dass die Leute anrufen.
Das ist das Outcome, das ich eigentlich erzielen will.
Mein Outcome ist nicht, für einen Fehler rauszumachen.
Mein Outcome ist die Verhaltensänderung, dass die Menschen weniger im Support anrufen.
Weil dieses Outcome, das zahlt auf mein Business ein,
weil dann brauche ich nicht mehr so viel Aufwand im Support.
Und jetzt kommt die Frage, wie kann ich das messen?
Ganz einfach.
Hier ist es ja super einfach.
Ich beobachte einfach, was passiert denn?
Woran kann ich denn erkennen, dass die Leute weniger Support in Anspruch nehmen?
Ja, es gibt weniger Tickets.
Es gibt weniger Telefonanrufe.
Und das sind die Dinge, die ich messen kann.
Das Schöne bei dieser Definition,
wenn ich also die Verhaltensänderung von Menschen betrachte,
ist, dass ich viel einfacher in die Messbarkeit komme.
Weil Verhaltensänderung ist etwas,
was ich mir tatsächlich irgendwie immer gut visuell vorstellen kann.
Ja, ich gucke einfach auf die Menschen und überlege mir,
woran kann ich denn das gewünschte Verhalten erkennen?
Und wie sieht das aus?
Das hat auch was mit Visualisierung zu tun.
Und dann erkenne ich irgendwann, oh, ja, es ist ganz einfach.
In dem Support-Beispiel rufen einfach weniger an.
Und die Verhaltensänderung,
die ich jetzt hier mit dem Podcast haben möchte, ist,
ich möchte einfach, dass Leute mich ansprechen und sagen,
hör mal, André, ich habe diesen tollen Podcast mit Dirk, Luca und dir gehört.
Lass uns mal ins Gespräch kommen.
Das ist eine Wirkung, die ich total wichtig finde.
Nicht, dass wir den Podcast durchgeführt haben.
Nicht, dass wir miteinander gesprochen haben.
Sondern die Verhaltensänderung von Menschen.
Und ich behaupte, das ist die Schlüsselfrage,
die sich im Produktmanagement und im Changemanagement immer gut stellen lässt.
Und ich behaupte, jetzt gehe ich sogar so weit
und nähere mich aber auch einer, vielleicht auch ein Stück weit einer Grenze.
Das ist die Schlüsselfrage, die ich beim Thema DevOps stelle.
Was will ich verändern bei den Nutzern,
beim Kunden, bei Mitarbeitern, bei Stakeholdern?
Oder wen auch immer?
Und wie kann ich erkennen, dass diese Verhaltensänderung eingetreten ist?
Wenn ich das als Outcome formuliere und sage, so Team,
das ist das Outcome, das wir jetzt erzielen wollen.
Überlegt euch, wie ihr das hinkriegt.
Keine Ahnung, ob das über Veränderungen der Software,
über Veränderungen der Prozesse, über Veränderungen der Kommunikation erfolgt.
Eigentlich egal.
Aber das ist das Outcome, das wir jetzt brauchen.
Ich erweitere den Lösungsraum.
Habe aber ein wunderbares Maß dafür zu erkennen,
habe ich das Thema gelöst oder nicht?
So war jetzt meine Bergpredigt zum Thema Outcome.
Wenn du mich jetzt sehen würdest, würdest du sehen,
wie ich hier ganz gespannt sitze und das, was du gerade alles sagst,
sozusagen verfolge und verarbeite.
Ich fange mal mit dem Einfachen an.
Was ich herausgenommen habe, ist, dass meine Sicht auf DevOps zumindestens
mit der von OKR quasi sozusagen total,
total übereinstimmt.
Es geht mir nicht darum, eine Organisation zu verändern,
also Dev und Ops in ein Team zu setzen.
Das ist eine Maßnahme, die ich machen kann,
aber die ich nicht machen muss.
Es geht darum, Verhalten zu verändern
und dass das zu einem besseren Ergebnis führt,
also zu einem besseren Outcome an der Stelle.
Insofern, das kann man sicherlich nochmal später beleuchten,
weil das passt jetzt in die Zeit von diesem Podcast nicht mehr rein.
Aber das war das Erste, was ich so rausgehört habe.
Aus deiner Bergpredigt eben.
Also da war ganz viel, ganz viel guter Input drin.
Das Erste habe ich eben zusammengefasst.
Luca, hast du noch ein paar Punkte, die dir eben so aufgefallen sind
bei Andrés Bergpredigt?
Ja, also aufgefallen in dem Sinne, weiß nicht.
Aber ich stelle halt fest, dass das wahnsinnig gut
zu unserer Perspektive von DevOps passt,
so wie du gesagt hast, Dirk.
Das ist diese Wertperspektive.
Das ist die Wertstromperspektive.
Das ist die Wichtigkeit von Feedback.
Alle diese Themen, weißt du, die drei Wege von DevOps.
Ja.
Die finden sich da eins zu eins wieder.
Und ich finde das ganz toll, was du gesagt hast, Dirk,
dass DevOps vielleicht gar nicht darin bestehen muss,
dass man die Dev- und die Ops-Leute in ein Team zusammenpackt.
Wenn man das macht, dann ist das ja vielleicht schön und nützlich.
Aber letzten Endes ist die Frage, bewirkt das was im Hinblick auf DevOps?
Bewirkt das was im Hinblick auf die Ziele, die wir uns gesetzt haben?
Ja.
Und das Interessante ist, wenn ich an meine Projekte denke,
da habe ich immer mal wieder Initiativen im DevOps-Bereich,
die auf mich zukommen, die aus diesen Fachbereichen kommen.
Das wollte ich vorhin noch sagen, zu der Sichtweise von Andy,
was für uns Führungskräfte sind.
Natürlich die Manager, aber auch die Fachleute.
Und ich habe immer, nee, nicht immer, das ist anders,
aber ich sehe häufig, dass die Fachleute,
also die Devler oder die Opsler, das ist unterschiedlich,
dass die ein besseres Ergebnis erzielen wollen.
Die sehen, dass es irgendwo nicht läuft,
dass der Kunde unzufrieden ist,
dass auch intern Maßnahmen nicht ein gutes Ergebnis bringen.
Das wird vielleicht nach außen hin kaschiert,
ist mindestens mal böse durch irgendwelche Manager oder wie auch immer.
Aber die Fachleute, die wissen, wo es brennt
und die wissen, wo es auch knackt, sag ich mal.
Und die kommen dann genau auch mit der Idee,
das zu verändern.
Und manchmal werden sie leider auch ausgebremst
durch die Aufbauorganisation.
Das ist das, was ich vorhin sagte.
Die kann man ja nicht ignorieren.
Aber insofern sind da viele, viele tolle Parallelen,
dieses Werkzeug umzusetzen.
Und das hast du ja vorhin auch, oder zu nutzen.
Das hast du ja vorhin auch gesagt.
Das sehe ich als eine sehr wichtige Parallele von Dev, Ops und von OKR.
Es gibt, es ist eine Art Philosophie.
Es ist Community getrieben.
Jeder bringt so seine Erfahrungen ein.
Und es gibt nicht einen, der sagt, so geht Dev, Ops.
Und so musst du das machen.
Also natürlich gibt es im Dev, Ops Umfeld Institutionen,
die Schulungen anbieten und Zertifikate anbieten.
Da sind wir ja auch mit dabei, Luca, Falco und ich.
Das machen mache ich aber quasi nur,
weil es manchmal so gewünscht wird.
Mir wäre es viel lieber, keine Zertifikate
und kein allmächtiges Wissen oder keinen Anspruch.
Genauso musst du das machen.
Es muss natürlich zum Kontext passen.
Ich sitze jetzt gerade hier im Dev, Ops Podcast
und stresse auch jetzt das Thema Outcome ein Stück weit
auch mit der Sicht von Produkten und Change.
Meine Definition von Outcome mag jetzt in einem Strategiekontext
nicht immer tragen, aber ich arbeite damit immer gerne,
weil es so wunderschön von der Innensicht ablenkt,
indem ich sage, was will ich denn draußen verändern?
Und weil die Veränderung menschlichen Verhaltens
für uns in der Regel auch immer gut vorstellbar ist,
wie man das in irgendeiner Form quantifizieren kann.
Ja, da kann man sich tatsächlich vorstellen,
was ist, wenn wir es einfach so lassen?
Das wäre dann die Baseline.
Und was ist, wenn ich mal die Idee maximal drehe?
Wir würden es extrem gut hinkriegen.
Wie würden sich die Leute dann verhalten?
Und das ist Variante B.
Und in der Regel kommen dann super schnell die ersten Ideen
für Konkrete, für Messbarkeit.
Die Messbarkeit ist für mich überhaupt kein Selbstzweck,
sondern passt für mich zu der Idee der agilen Arbeit.
Also empirisch vorzugehen, datengetrieben vorzugeben,
Experimente zu wagen, die diesem Outcome hoffentlich näher kommen,
die aber manchmal auch scheitern,
und dann ein anderes Experiment zu wagen.
Und dafür brauche ich einfach, da bin ich komplett bei Andy,
Messbarkeit.
Um zu erkennen, hey, haben wir das jetzt geschafft oder nicht?
Ja.
Ja gut, jetzt haben wir das Thema,
was wir, wie gesagt, nicht mehr diskutieren können aufgrund der Zeit.
Diese Messbarkeit kann natürlich auch falsch verwendet werden
oder falsch interpretiert werden.
Du sprichst, hast du vorhin angesprochen, Zielvereinbarungen.
Das lassen wir jetzt mal außen vor.
Vielleicht können wir das ja zu einer späteren Folge nochmal machen.
Oder vielleicht machen wir da irgendwie nochmal einen Artikel draus oder so.
Denn ich habe vorhin eingangs gesagt,
dass wir im Vorgespräch, du auch herausgefunden hast,
OKRs und im Kontext von DevOps hast du nichts oder nur wenig gefunden.
Ist das so oder gibt es, das ist wirklich so,
oder gibt es nicht wirklich irgendwo mal so eine Art Geheimtipp
von anderen Klassen versatiert?
Das finde ich gut.
Also können wir unseren Zuhörern noch ein paar Dinge mitgeben,
die wir auch in die Shownotes packen, wo sie etwas nachlesen können
oder nachschauen können.
Also was ich mittlerweile gelernt habe, ist,
was beim Thema OKR ist, ist auch wirklich ein Tipp von mir.
Schaut nicht so sehr nach Beispielen aus dem Internet,
weil es gibt keine guten generischen Beispiele.
Es passt in der Regel nicht zu den eigenen Fragestellungen.
Also was ich jetzt bei DevOps wieder mal gesehen habe,
sind so konkrete Beispiele, die sich um technische Fragen reden.
Erhöhung der Verfügbarkeit von 90 auf 95 Prozent und solche Dinge.
Oder Reduktion der, weiß ich nicht,
Antwortzeiten XY.
Ja, auch das kann ich als OKR formulieren.
Aber das ist so weit weg von dem, was ich als Outcome bezeichne.
Was ist denn das Outcome?
Was wird da erreicht worden?
Was ist die Verhaltensänderung, die uns dazu führt,
auf diese Idee zu kommen?
Und die möchte ich gerne formulieren.
Also die DevOps-Beispiele sind ganz oft genau da,
wo ich auch das Thema DevOps nicht sehen möchte.
Bei der untersten Maschinenschraube, sage ich jetzt mal.
Und da gefallen mir OKR-Beispiele.
Da gefallen mir OKR-Beispiele genauso wenig wie DevOps-Beispiele.
Auch wenn ich diese Maschinenschrauben beherrschen können muss,
um diesen Impact, diese Wirkung zu erzielen.
Also ich will das nicht kleinreden.
Aber das ist nicht die Ebene oder die einzige Flughöhe,
über die ich nachdenken darf.
Und im Sinne von OKR ist es wahrscheinlich die letzte Flughöhe.
Was ich aber gefunden habe und was mir sehr, sehr gut gefällt,
ist ein Buchtipp in dem Zusammenhang.
Das ist das Buch Accelerate, an dem auch der Gene Kim mitgeschrieben hat.
Da wird der Begriff OKR überhaupt nicht benutzt.
Also werdet ihr keine OKRs finden.
Aber da wird das Thema Outcome und Messbarkeit thematisiert
im Zusammenhang mit DevOps.
Und darum geht es.
OKRs sind am Ende des Tages nur ein Framework,
das euch ein Stück weit hilft, in dieses Denken besser reinzukommen.
Aber was ich wirklich brauche, ist ein Gefühl dafür zu entwickeln,
okay, was ist denn die wirkliche Wirkung,
die wir mit den Produkten erreichen wollen?
Wie können wir die hart messbar machen?
Und dann letztendlich die gesamte Wertschöpfungskette verbessern.
Also mein Buchtipp ist Accelerate.
Kommt auch in die Buchtipps rein.
Dann habe ich ein schönes Video gefunden,
das das Thema Outcome basiert.
Das Thema Outcome-Based Planning.
Nicht so sehr aus DevOps-Sicht,
aber aus Sicht von Produktmanagement beschreibt.
Präsentation heißt Roadmaps are dead.
Wunderbare Präsentation.
Also ich habe ganz viele Aha-Erlebnisse gehabt.
Kann man wirklich empfehlen.
Zehn Minuten super gut investierte Zeit.
Auch für das Thema DevOps wird ganz knallhart.
Werden die wichtigsten Learnings, die wir alle mittlerweile haben,
durchexhaustiert.
Und dann kommen drei goldene Tipps.
Die haben alle was mit Outcomes zu tun.
Ja, ansonsten ein bisschen Eigenwerbung.
Kommt gerne auf meine Seite andrejklaassen.de.
Und ich habe natürlich auch einen Podcast zu dem Thema OKR.
Und werde übrigens ein kleiner Teaser jetzt auch in den nächsten Monaten
stärker auf das Thema Produkte schauen,
das Thema Outcome nochmal mehr beleuchten.
Übrigens auch mein Lieblingsthema Messbarkeit.
Da gerne auch drauf schauen.
Sehr schön.
Gut, also Eigenwerbung ist immer erlaubt.
Zumindest auf gute Themen.
Und wir haben dich ja in den Podcast eingeladen,
weil wir glauben, dass du da ein Experte bist.
Und dann darf auch Eigenwerbung erlaubt sein.
Du hast noch was von einem Buch erzählt von Josch Seiden.
Ah ja, genau.
Josch Seiden.
Also das, was ich hier in meiner Bergpredigt formuliert habe,
ist in Wirklichkeit die Bergpredigt von Josch Seiden.
Und jetzt Gotthelf.
Das sind zwei englische Experten,
die sich seit ganz vielen Jahren mit dem Thema
Inspect and Adapt, Sense and Response und Outcomes beschäftigen.
Es gibt ein Buch, das braucht wirklich nur 40 Minuten.
Outcome over Output.
Da wird diese Outcome-basierende Planung von A bis Z durchgespielt.
Auch das Thema OKR findet da Raum.
Auch das Thema DevOps wird dort erwähnt.
Mein Feedback zu dem Buch ist, jede Seite ist Gold wert.
Die beiden, man merkt denen einfach deren unfassbare Kompetenz an.
Und für mich ist das so etwas, wo alle Koryphäen oder Leute,
die ich so ein bisschen als Koryphäen sehe,
stückweit zusammenkommen.
Eben in diesem Denken, ob es ein Dan Norris ist,
ich weiß nicht, ob der bekannt ist,
Urgestein der agilen Szene,
der schon 2006 gesagt hat,
wir brauchen eigentlich ein fünftes Prinzip im agilen Manifest.
Das ist das Prinzip Outcome.
Ob es Jeff Sutherland ist,
der ja Scrum miterfunden hat,
der immer wieder auf das Thema Outcome,
wenn man dem mal zuhört, zu sprechen kommt.
Oder jetzt hier der Josh Seiden.
Es gibt auch noch ganz viele andere, die ich empfehlen kann.
Da habe ich aber jetzt nicht Mike Burrows unbedingt zu.
Man hat so viel zu erzählen.
Es geht genau um dieses Thema.
Und was ich schön finde an dem Buch Outcome over Output,
es beschreibt auch ganz klar,
warum Führungskräfte sich so schwer tun mit dem Thema.
Denn es hat auch was mit Kontrollverlust zu tun.
Und das wäre aber ein eigener Podcast.
Allerdings.
Das ist keine böse Absicht,
sondern das ist einfach ein Stück weit auch,
hier kommt so ein Punkt, wo auf einmal
ein ganz anderes Führungsverständnis erforderlich ist.
Etwas, was ja auch DevOps schwer macht
oder richtige agile Arbeit.
Und das ist auch ein Thema in dem Buch.
Also bevor ihr auf meine Webseite geht,
dieses Buch lesen.
Okay.
Jetzt war Luca wahrscheinlich aus gutem Grund
immer so ganz still.
Jetzt kommt meine Werbung für Luca.
Wenn du also in deinem Podcast jemanden suchst,
der das Buch Accelerate gelesen hat,
intensiv gelesen hat und auch verstanden hat,
dann kann ich dir Luca Njani als Gesprächspartner empfehlen.
Vielleicht kann man da auch was rausziehen.
Gerade weil du gerade sagst,
dass da ja nichts über OKRs drinsteht,
aber trotzdem ganz viel Übermessung drinsteht.
Also insofern Werbung für meinen lieben netten Kollegen Luca.
Dankeschön.
Gut.
Dann sage ich aus meiner Sicht,
ich habe keine Fragen mehr.
Es kommt ja von mir häufig die Frage,
gibt es noch irgendwas Wichtiges,
was wir nicht angesprochen haben?
Aber ich glaube, André,
du hast so viel angesprochen,
dass du auf jeden Fall die wichtigsten Themen,
die du so platzieren wolltest,
die für dich wichtig sind,
dass du die angesprochen hast, oder?
Ich glaube, wir sind durch.
Wir haben jetzt eine Stunde gesprochen.
Enough is enough, würde ich sagen.
Ganz herzlichen Dank an euch beiden,
dass ich heute bei euch zu Gast sein durfte.
Sorry, dass ich so viel geredet habe.
Ich hätte vielleicht doch keinen Kaffee
vor dem Podcast trinken sollen.
Vielleicht ein bisschen eher Beruhigungstee oder so.
Aber mir hat es gefallen.
Und ich habe immer die Frage,
ob man dem Gespräch,
ob man der Aussage,
dem Monolog,
ob man dem gut zuhören kann.
Und ich konnte dir zuhören,
weil da zum Beispiel wenig Äs oder Äms drin waren,
weil man einen klaren Gesprächsfluss hatte und so weiter.
Also insofern, du hast vielleicht viel gesprochen,
aber ich fand es nicht störend.
Ich fand es im Gegenteil sehr, sehr,
ich sage mal unterhaltsam und sehr, sehr lehrreich.
Und ich konnte dir gut zuhören.
Und ich hoffe,
dass das dann den Teilnehmern auch so geht.
Wunderbar.
Ganz herzlichen Dank an euch beiden.
Und vielleicht hören wir uns ja nochmal in dieser Runde,
in diesem oder in dem.
Oder in einem anderen Podcast.
Ja, das wäre doch cool.
Ich dachte, du sagst in diesem Podcast oder in einem anderen Leben.
Ja, ja.
Okay, gut.
Alles klar.
Bis bald.
Alles Gute.
Und André, dir noch einen schönen Tag.
Und Luca, dir auch alles Gute bei dem,
was du jetzt vielleicht irgendwie nochmal tust.
Ja.
Tschüss.
Genau.
Dankeschön.
Macht’s gut.
Danke für das Gespräch, André.
Ciao.
Danke.
Tschüss.
Tschüssi.
Ciao.
Tschüssi.
Ciao.
Ciao.
Ciao.
Ciao.
Ciao.
Ciao.
Ciao.
Ciao.
Ciao.
Ciao.

Klicken Sie auf den unteren Button, um den Inhalt von podcasters.spotify.com zu laden.

Inhalt laden

In this episode we’re joined by medical devices specialist Jeff Gable, whose mission it is to „drag embedded development kicking and screaming into the 21st century“.
He tells us about the specific issues when applying DevOps principles to embedded systems, from the technical to the cultural.

In this episode, Luca Ingianni and Dierk Söllner interview Jeff Gable, an embedded software consultant in the medical device industry, about the challenges and opportunities in applying agile and DevOps principles to embedded systems development. Jeff highlights the unique aspects of embedded systems, such as hardware involvement and slower iteration cycles, and delves into how these can be addressed through modern software techniques. He also discusses the cultural and regulatory challenges in the medical device industry, stressing the importance of agile documentation, risk management, and continuous improvement within these constraints. The episode concludes with a focus on the potential benefits and future prospects of implementing agile and DevOps in hardware and safety-critical industries.

Inhalt

• Introduction of hosts and guest, Jeff Gable
• Jeff’s background in embedded software for the medical device industry
• Discussion on DevOps principles and their application in embedded systems
• Differences between DevOps in web and embedded systems
• Challenges of implementing agile and DevOps in hardware and regulated environments
• Agile documentation and risk management in medical devices
• Leveraging modern tools and platforms in embedded systems
• Cultural challenges in adopting agile and DevOps in traditional industries
• Potential of agile and DevOps in safety-critical environments
• Jeff Gable’s resources and recommendations for further learning

Shownotes

Jeff’s Website

Transkript (automatisiert erstellt, wer Fehler findet darf sie behalten)

Welcome to a new episode of DevOps auf die Ohren und ins Hirn, or in English, DevOps from your ears straight to your brain.
Usually, this is a German-language podcast, but we sometimes make exceptions for international guests.
Today is one such exception.
My name is Luca Ingianni and I host this podcast together with my colleague Dierk Söllner.
We’re both DevOps consultants, trainers and coaches, trying to get teams to work together better and create better products for their customers.
Today we’re joined by Jeff Gable.
Jeff is an embedded software consultant for the medical device industry.
And his mission is to drag medical device software development kicking and screaming into the 21st century.
Jeff, welcome to the show.
Hi, Luca. Hi, Dirk. It’s great to be here. Thank you.
Hi, Jeff. Great to have you here. I want to give you a warm welcome.
Thank you.
Could you please give us a short impression to introduce you?
How would you introduce yourself?
Sure. So, as Luca said, I’m an embedded software consultant.
I’m an embedded software consultant and I’m focused on the medical device industry.
And the medical device industry in general is way behind the times in terms of adopting modern software development techniques and principles.
And so it’s, as Luca said, it’s my mission to drag the medical device industry kicking and screaming into the 21st century.
I’m trying to introduce agile software techniques, DevOps principles.
And, you know, starting at the technical level and moving up the organizational level.
And, yeah, I’ve been a solo consultant for three years and it’s been a fun journey.
Awesome.
Since you spoke about DevOps, we usually have this tradition on the podcast of having our guests explain to us their definition of DevOps.
So what’s yours?
Sure. So DevOps is obviously the amalgamation of development and operations.
And I think at its most fundamental level, it’s about breaking down the silos and treating the production of a software product in a more system, with a system level view in a more holistic way, as opposed to the way it was done before DevOps was introduced, which was in a very siloed way.
And there’s certainly, you know, there’s lots of other principles that come along with it, but I think that’s the most fundamental level.
For me, at least.
Okay. Are there some difference between DevOps in your industry and the normal industry for Luca and me?
Sure. So my understanding is, you know, you guys are focused in the web development world and my focus is in the embedded device world.
And I’m not an experienced web developer. I’ve done some.
But I’ll say the two most obvious.
The two most obvious differences to me are, one, in embedded systems, there’s hardware involved.
And hardware is just trickier to do in an agile context.
The iteration time is fundamentally slower.
There are, Luca and I have talked about this on our own podcast, that there are ways to speed that up.
But fundamentally, hardware adds this complication that just isn’t there in the world of web development.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
you know we’re not doing this well we want to be more agile we want to start doing this in a more
modern way they don’t have that really mature set of tooling and practices that they could just draw
from they have to figure out a lot of things along the way and cut themselves on a lot of hard edges
um and and so that those two things i think the heart the fact that hardware has a slower
iteration time and the fact that the tooling is less mature are the two main differences
yeah i was just going to ask like what are you even doing on this podcast you’re doing hardware
aren’t you um how does that like does does devops even apply to your line of work absolutely so so
i am not a hardware engineer myself i’m a i’m a software engineer so i write uh embedded software
and firmware uh and so very very much i i try to apply devops principles in my daily work
and and and and and and and and and and and and and and and and and and and and and and and
convince the others around me to do the same uh but it can it can be an uphill climb how so
like why is it hard to convince people to do devops and hardware
uh because essentially it it requires a different architecture maybe in terms of how you actually
write the software so you can’t just take kind of a traditional embedded software application
uh that was written without this in mind and just kind of do devops
on it like there’s uh in order to even um do take the most fundamental technical steps like
setting up a continuous integration server doing automated builds uh starting to do unit testing
uh your your application has to be architected in a way that supports that and that’s often not
the case for someone who didn’t write an application with that in mind so it often
you know especially if you come into a legacy program where there’s a lot of code built up
it’s really hard even to take that very first step uh and that’s if you’re motivated to do so
a lot of people just don’t see don’t really get it and don’t understand the value in it
and so that’s that’s where it just takes longer to convince them you have to you have to do those
architectural changes yourself get it going start to start to uh demonstrate some benefits before
people really see the value in it okay let me let me ask about this again just because you
pointed out that you’re not a developer you’re not a developer you’re not a developer you’re not a developer
iteration speeds are slower you know everything’s maybe more complicated and clunkier
can you even reap the benefits of agile development and of and of devops in uh you know especially
maybe in safety critical industries like medical devices or something or are you just fundamentally
shackled to maybe a half year or yearly release cycles and you know and you really have no chance
to iterate quickly as agile would want you to do sure so so again because my focus is in embedded
software and because i’ve architected my software to uh be as uh divorced from the hardware as is
practical um my software development definitely takes advantage of agile principles and i can
iterate very quickly um i i think from it if you look at it so you can you can have kind of an
agile software department within a organization that is not agile and i’m maybe you guys have
have touched on this in the past where uh you know if someone has a software that’s not agile
your audience you know they’re a mid-level software manager say and they they want to start
making things better but they’re stuck in this organization that is say more waterfall driven
um you can still do a lot within the area over which you have control you just can’t you know
maybe the organization will never come along uh the way you would like it to but you can still
get a lot done in the in your own department and so in my sense you know even if even if i’m working
with a medical device company and i’m not a software manager i’m not a software manager
and the hardware releases are six months apart i can still do lots of software iteration in the
meantime um and i can even get the software ahead of the hardware and demonstrate that it’s working
in simulation or emulation and then inform the hardware what changes they need to make
encouraging them do it more quickly that can be more of a challenge
so in the end i suppose it comes down to that principle principle that we talk about
in quote-unquote ordinary devops as well which is um autonomy right you you need to be sort of
insulated from from the hardware and conversely i suppose the hardware from you so that everybody
can move along at their own pace would that be the right kind of understanding sure i i i think
that’s a that’s a really good way to put it certainly yeah the software needs to be
insulated from the hardware it’s it’s i haven’t really considered whether the
hardware needs to be insulated from the software in that way um i suppose in the in the sense that
the hardware team should be they should get input from the software engineers obviously
but they should not feel constrained from making a change because it will cause problems in the
software and that’s where um actually having a good software architecture that’s decoupled
and divorced from the hardware the hardware should be able to change out from under you
you as the software developer and
it shouldn’t cause you a lot of problems and that because you’ve architected your software in that way
now the hardware team is free to change things more rapidly um if they find a new sensor or new
component uh that has better performance no no longer is it going to be well don’t change that
because the software can’t support it you know or it’ll take forever in software to write a new
driver for that so so yes actually i think i think it does it works in both ways it helps both the
hardware team and the software team to have that
uh good software architecture that minimizes the dependence between the two
very interesting so even even though maybe the circumstances changed all the underlying
principles are you know just as applicable aren’t they right i mean if you look at you know kind of
gene kim’s three ways of devops and and uh looking at things from a systems perspective to try to
move the you know increase the the speed of the flow of work through the system all the way to the
uh increasing the speed of the feedback feedback loops to get information back upstream um and
practicing continuous improvement those you know those three principles are valid in almost any
context and can like the way you apply them may differ but but i absolutely think those those
principles are are just useful in any context you said that that um embedded is 10 15 maybe 20 years
behind the times what like what what does that mean for the practical work of developers or
engineers right so it means that essentially if you want to take this this agile transformation
journey uh as an embedded developer you know there are not as many um best practices figured
out for you you’re gonna like i said you’re gonna cut yourself on some sharp edges
of the tooling the the tooling in particular uh there are starting to be services coming online
that i think will provide a lot of power and utility and take care of a lot of the really
messy details um services that come to mind uh memfault which makes remote uh monitoring and
debugging very easy uh platform io which is a you know just a general embedded iot platform
takes care of a lot of the the cloud service details for you uh and over-the-air updates
that kind of thing um renode is a very good simulator emulation platform rather that makes
that much easier it’s kind of docker for embedded emulation you know docker is now how old is docker
10 years i guess so right so so docker is behind you know and and again because i am not an
experienced web developer you know maybe i say the word docker and that already dates me um you know
and and luca’s nodding has said yes um so anyway so so and even you know maybe in the web
development world i’m sure there’s a lot of controversy on the bleeding edge you know
people are really into kubernetes and other people very anti-kubernetes whatever
uh the point is is that that industry has has progressed really to the next level in terms of
enabling smaller development teams to accomplish more and more and that is just now and that’s
been the case for a long time and that’s been the case for a long time and that’s been the case for a long time
time in the web development world that’s really just now coming online in the embedded world
and so it’s an exciting time in the embedded development world because all of these services
are just now becoming available and getting mature uh but even so simply setting up a
continuous integration server a lot of it is built for web development and to apply it to
embedded development just takes some a lot of fiddling and configuring and um you know you have
uh integrated development environments and debuggers that are designed to work with the
hardware and you know there it’s hard to get the usb connection to your to your sandbox you know
things so it’s uh that’s what i’m saying is the the practical different effect on the day-to-day
work is that there’s going to be a lot more uh an embedded developer will have to um figure a lot
of these things out on their own okay um jeff you’re talking about difference between embedded
and web development
absolutely the culture is the same way um especially especially in the regulated
industries uh so where i come from medical devices and i’m certain you know aerospace
automotive um nuclear power plant development that kind of thing uh they’re going to be even
farther so i i haven’t actually done very many um consumer electronic projects uh so
i would imagine that’s a little more stratified in terms of there are still people doing
consumer electronics that have no idea uh and there are people doing consumer electronics who
are quite modern and are taking advantage of all of these services that i just mentioned
or developing themselves uh so yeah so the the the culture of these organizations um i i think
is also very behind again there’s a bit of that chicken and egg problem like it’s if you want to
change the culture you’ve got to show the benefits but if you want to change the culture you’ve got to
like actually accomplish the technical tasks and the tooling makes that difficult which means you
don’t have anything to show for it which means it’s hard to change the culture um and so on and so on
and so on and so on and so on and so on so you gotta you have to be a source of excellence and
just uh drive your organization forward in whatever way you can uh regarding um the the silos
hardware yes and software um what what do you think or do you know some
some teams which are uh cross-functional so where you develop the hardware and the software
within one team uh yes and and you know in the medical device world there are a lot of
startups uh where it’s basically just a few people so it’s really the entire company is
only a few people it’s all one product team working on one product uh and so in in such
companies the uh the electrical engineer and the firmware developer are going to be working on
very close to each other and what you would hope from a cultural perspective is they’re they’re
extremely collaborative um you know the the the classic interaction is they’re both blaming each
other the problems i think it’s in hardware no i think it’s in software i that really doesn’t
happen quite as often as as you might fear um but yeah i i guess um that’s something i i like
and especially with my background my degrees are actually in mechanical engineering and i’ve done
um i haven’t designed any pcbs but i’ve done a lot of pc pcb schematic review and so you know
everyone having to um and then again i’ve tried to teach uh software skills to my
double e and me counterparts so they at least understand a little bit of my world so
um certainly the more you can do to infuse the skill sets that will also
help to infuse the mindset and add some empathy and enable you to be more cross-functional
yeah but i’m not sure whether that mirrors your experience like i’ve often experienced that
you know even though everybody’s meaning well and trying really hard to work together and be
cross-functional especially like mechanical engineers and software engineers come just
come from very different worlds in in terms of like their traditions even off of maybe
expressing technical ideas um
how much of a stumbling block has that been for you i i think it is a stumbling block in the
industry i i can’t speak to it that intelligently just because i happen to have that cross-functional
background that’s my that’s my own personal engineering background and most of my work
is with small teams uh but i would certainly imagine in larger larger medical device
organizations say um like i don’t know johnson and johnson or edward scientific or you know
these really really big organizations
there is there is probably a lot of that where you have silo development you have the
mechanical department and the electrical department and the and the firmware department
they probably a lot of companies don’t form these product development teams where you have
a cross-functional group working on a single product line yeah i imagine it is it is a real
a real issue so there’s another question that i’ve been meaning to ask because
now you’ve persuaded me that okay devops works for for embedded systems works for for hardware
adjacent products i suppose or you know products combining hardware but now you come from an
even maybe more difficult world which is the world of medical devices you know a regulated
industry a safety critical industry where you can’t just do whatever you want and iterate
whichever way you want and then looks good let’s let’s deploy it and then you know somebody’s
pacemaker fries and that’s like not a good thing does devops does agile work in safety
critical environments in regulated industries
yes yes it does there and there’s uh it’s a hot topic in medical devices right now
uh and and the fda has you know issued guidances on this and there’s been technical information
reports that kind of try to clear up this misconception that um agile development is
is incompatible with with being safety critical trying to get concrete as i like to do the the
way that you the things that separate say regulated industries or safety critical industries from
those
that are not so fundamentally it’s uh risk analysis and risk management um so like when
you say you know you you’re putting a pacemaker in someone and if you make a mistake it could
kill them essentially the the way that you do that is you know you first come up with this
concept of this pacemaker how it’s technically the work how are you even going to regulate
someone’s heartbeat and then you very methodically and thoroughly think of everything that could go
wrong and the probability that it’s going to happen and the severity
of of what it does and then you introduce additional requirements into your engineering
requirements into your system to mitigate those risks and to bring them down to an acceptable
level and you know the fda in in particular for medical devices um gives you this this
high level process to accomplish that but they don’t necessarily specify the details that’s up
to your company but that’s that’s what you need to do to produce a safety critical device that’s not
harm to a patient you can still do that in an agile context the i would say the difference is
is that what you think of as a sprint where you where you actually release a device to a to a
customer there’s going to be internal product development sprints but if you think of an
overall iteration of you come up with a concept and you you clear it past the fda and you put
it to market that broadest definition of an iteration that will be more slow that will be
slower than say a web development project but it still can be a lot faster than it has been in the
past and essentially you do that by really being ruthless with the number of requirements that go
into that version one and then you still have to do all the steps you still have to do the risk
management you have to specify requirements for each of the engineering disciplines you have to
verify them on the back end you have to validate the device but going to market with a truly
minimum viable product absolutely
works in in that context you just have to follow all the steps you you just don’t you don’t do this
multi-year uh development effort you can do it in one year it still may drive people nuts that you
know you you’re not uh you know maybe people in your audience that are are used to much much
faster iteration times and you can still do those very fast iteration times within the product
development cycle like as you’re like i said as you’re actually writing the firmware for your
device you can realize oh it’s not going to work that way you’re not going to be able to do that
the way that we think it was we need to change and you make that feedback loop as fast as possible
but your overall iteration you can certainly cut from years to a year but that still sounds to me
like you you have some kind of a waterfall start to the process anyway where you do your safety
analysis and you write down your requirements like in the like in the bad old days you write
it all down up front and then you pass it on to the developers and they you know do their thing
is that really what’s happening or do you even
iterate on like your safety case and and whatnot absolutely yeah you certainly iterate on on the
even within that that shortened product development cycle you certainly iterate on the requirements
you iterate on the risk management and and you need to set up your tooling and so at that point
it’s not it’s when i say tooling at that point it’s no longer just the engineering tooling you
know your your continuous integration server thing but it’s it’s the software they’re using
for requirements management the software they’re
you’re using to manage test cases and link the two together to verify that all your requirements
are actually tested those tools need to be set up to support this rapid iteration of requirements
and that that is where the medical device industry is way behind and a lot of people are still
writing word documents and excel files to manage these things and linking them by hand which is
horribly error prone and takes a long time and so that’s great if you write it once and never
change it but as we all know it changes constantly and so that’s great if you write it once and never
change it but as we all know it changes constantly and so that’s great if you write it once and never
continue so you should automate excel
also
um
should automate is the creation of documents so in the end there needs to be a pdf
that goes to the fda that lists out all your requirements and knows which requirements you’re
required to semicolon um and both do that but at that point it just activates a blockchain mechanism
that goes to the fda that lists out all your requirements and knows putting yourself
resources and sometimes you too way we it takes more time u need x my hours x multiple times
で to make this possible and what you should automate is the creation of documents so in the end there
needs to be a pdf that goes to the fda that lists out all your requirements and knows which certain
requirements and lists out all your test plans and shows the results of running those
individual tests, those documents, the production of them from this tool that you actually work
in, you absolutely should automate the production of those documents rather than working in
Word directly.
Because then, as those inevitably change over the course of a project, you don’t have
this parallel effort of trying to keep them up to date.
They’re kept up to date naturally and linking all of the wonderful things that databases
enable behind the scenes can be automatically reflected in your documents.
And that’s something really interesting that I think is worth pointing out, that you have
to modernize, not just make agile, not just your product development in terms of maybe
code, but also really the…
The requirements management side, because traditional agile, quote unquote, maybe is
fairly light on requirements management.
You have a bunch of user stories and you keep them in a backlog and that’s it, essentially.
Like there is no tracking, there is no, what’s the word, I’m blanking on it, traceability.
But of course, the FDA requires these kinds of things.
So you have to almost separately agilize.
It sounds like…
It sounds like the requirements engineering side of your product development.
Absolutely.
Yeah.
So the regulatory and quality teams in, say, a medical device company need to get on board
with this.
And it’s funny in my work, so I know a lot of medical device quality and regulatory people.
One woman I’m thinking of in particular is extremely competent, extremely well-knowledged,
and she hates agile because…
Teams that she’s worked with in the past that have said they were agile used as an excuse
to not do the necessary work.
They used it as a crutch to basically say, oh, we’re agile, we don’t actually need to
write requirements or like, you know, we’re going to take our JIRA user stories and just
kind of like literally print it from the screen.
And the format is completely unsuitable.
It’s not useful for anyone else.
So they’re not thinking it’s…
The problem is, is the development team she’s worked with weren’t thinking from a system
perspective.
Because in medical devices, the system includes generating documents that are going to be
read by the FDA.
You don’t get to sell a medical device without them.
So it’s a necessary component.
You can’t say, oh, we’re agile in our development process and we’ve made this device in half
the time that we used to or whatever.
It does no good if you can’t get it past FDA and sell it.
You know, I told her recently, I can’t wait for the two of us to work on a project together
so that she can see how good agile documentation can be.
And she said, great.
Can’t wait.
So when we do finally work together, I’ll have to put my money where my mouth is.
Yeah, that’s interesting.
Like, this is something that I also encounter in other contexts quite frequently that,
you know, your idea of what your product constitutes needs to change.
Your product is not just the widget that you build.
It’s not just the pacemaker.
It’s also the documentation for the FDA.
And so you also need to, as you hinted at before, you need to create that.
Not in an agile way.
Correct.
And recognize.
So the problem is, is that people, because they still have this waterfall mentality,
they don’t invest in improving that tooling or that process.
And so then changing it is a real pain.
It’s full of a lot of friction.
And so then they do that classic vicious cycle where they don’t want to do it as often.
And that’s, you know, sends you down this road path of very waterfall based development
when it’s just.
Not real, whereas we all know that, you know, if something is painful, do it more often.
So if it’s painful to update your risk management and then update your requirements and then
update the traceability matrix, automate it so that it is painless and systematize that
process so that, you know, every time, oh, I just thought of something that needs to change
in our risk management, like from that aha moment to the documentation is updated and that
not just for the documentation sake, but that as an engineering organization, you’ve
you’ve done your due diligence and you are confident that your device is safe, that
you have not introduced any risk or that you have mitigated any additional risks that
you’ve introduced.
You satisfy yourself first and then satisfy the FDA.
Anyway, from that aha moment of realizing something needs to change until it is actually
changed and is ready to go to the FDA that you need to smooth and automate as much as
possible.
And a lot of people just don’t go.
Through that effort.
Sometimes I think automation is even a question of of mindset.
If I look to my to my customers, I see the younger guys, they are too.
Oh, I don’t know the English word for foul.
You can’t smoke with half and lazy, lazy.
They are too lazy to do the second thing again.
So they automated and the older people.
They are not too lazy.
For them, they are busy and so maybe it’s a little bit a little bit black and white
looking.
But what do you think?
Do you do you see that too?
It’s so I’ve often heard that like, oh, software software developers do all this
investment because they’re lazy and they don’t want to keep doing things.
And and for the easy things, that’s true.
But when when automation requires a fair amount of investment.
I, I don’t think that whether you’re lazy or not will will determine which way you go.
It’s it’s really it’s having that faith that like sometimes automation requires an
investment of effort.
And if I’m lazy, I’m going to avoid doing that, you know, in one sense.
So like if it so so that making that short term sacrifice for long term gain, you know,
cutting your development velocity down in the short term.
Knowing that.
In three months, it’s going to be much faster, that takes a certain amount of forward
thinking and faith that that process is going to turn out, turn out.
And and it takes a management and leadership team that’s going to support that.
Either they have faith that it will pay off or they’ve created a culture where failure,
occasional failure is okay, that that a culture of experimentation.
We’re going to try this and maybe this specific effort won’t pay off, but overall, the fact
that we as an organization.
Are experimenting with new ways to improve that will pay off, so it’s fine.
Yeah, I’ve I’ve often heard the lazy trope and I I I think it’s it’s it’s very it applies
to things that require very low investment, then your laziness will clearly drive you
to make that quick win and that quick script.
But when something takes more time, it’s I don’t know that that’s the best way to to
think about it.
Yeah, that’s the thing, right?
Also with with technical debt, for instance, in general, and and I suppose you could
talk about automation in terms of process that, you know, you’re trading future velocity
for present velocity, right?
Yeah, absolutely.
If you have that, go ahead.
Go ahead, Dirk.
No, it’s it’s it was just one one remark, because if I’m if I’m working as a coach,
it’s not very cherished to to say you are lazy.
So just just a small footnote.
Got it.
Got it.
So but but I mean, you are making a very.
Compelling argument for why Agile and and DevOps really should be in every engineers
and and every business’s best interest.
And it should really be, I suppose, the industry standard.
So why isn’t it?
Or is it?
I don’t think it is, is it?
So again, I I can only speak to the medical device industry, but it’s certainly not there,
though it is it is becoming more accepted.
There is more and more talk about there’s official guidance document, which, you know,
a lot of the.
The legacy companies kind of always look to there’s now official cover from the FDA to
allow them to pursue this, though, I will say so so another way to divide up the maybe
the audience or the people who have to actually handle this in in real life, there’s more
established companies that maybe have a suite of products or quite a few different product
lines and they’re coming out with new versions every few years and then there are
startups who spring into existence.
One of the bigpeda will become solely for the purpose of releasing the single product and
they’re just hoping for an acquisition.
Those those startup teams that are there are often sometimes there are none of them are
full-time employees.
That’s actually a project that I’m working on right now is the two founders and a bunch
of consultants.
These these teams that spring into existence for a single purpose and then disband, they
are going to have a harder time.
Applying DevOps.
organization as a whole has less time to continuously improve.
You can think of a larger organization that really believes in these principles.
They’re going to learn from one project
and apply it to the next and then apply it to the next.
And yes, even within each project, of course, they’re continually improving.
But sometimes some lessons aren’t learned until the end of the project.
And I think that that’s not my way of thinking of Agile or being Agile
and DevOps, because you have to build up teams who are working for a long time together.
Right, right.
That’s where you’re going to get the most
wins, is where your team has time to continuously improve.
And in the embedded world and especially in the medical device world,
there are startups that are literally only together for three years
before their technology gets acquired by a larger company and off they go.
And so there’s just
not a lot of time there to really improve.
And so that’s, you know, as a consultant, that’s the kind of project I’m involved with.
And so I bring in, you know, I’m working on applying DevOps to my own work.
But in terms of coming into an organization
and really affecting change at the organizational level,
it is much more challenging and sometimes I just can’t do it.
I have to work within the constraints of the organization I’m in.
And there’s not that time to, say, build that credibility
to then
leverage it into organizational change.
Luca and I not too long ago talked with a man named Joe Schneider.
He runs an embedded consultancy here in the States.
But for a long time he worked for John Deere, which is this agricultural company.
They make tractors and agricultural equipment.
You know, think of a legacy company.
But he was with them when they started
their agile transformation of their firmware development group.
And this was a large company.
And there were 400 firmware engineers by the time he was done.
And it took you know, he was there for 10 years.
And over that time, the organization as a whole made huge improvements.
And they started with this little kernel of technical practices and slowly over
time transformed that into or that that evolved into an organizational transformation.
And if you’re a startup, you just may not have time to do it.
Yeah, that’s actually an important point to make, I guess, that there’s just so much
more to think of in embedded systems than in quote unquote ordinary software work.
Because you have all the challenges of software.
Plus you have the challenges of hardware.
Plus you have the challenges of documentation, of regulation, potentially anyway.
Plus you have the challenge of not being able to continuously deploy your code.
Or at least I would feel a bit uneasy about over the air updates for pacemakers.
Is that actually a thing?
So not for pacemakers.
I would say for so the FDA kind of has different risk level classifications,
class one, two and three and pacemakers are class three, which meaning that a they
could cause severe injury or death, you know, class two, which is they could
cause moderate injury or class one is minor or no injury.
Class one is a Band-Aid, class two is a diagnostic device that’s returning a
a diagnosis.
Or or some kind of treatment device that, you know, is not treats your eye maybe
or something, but is not life critical.
So certainly medical IoT is also a hot topic and people are doing over their
updates, but I imagine they are not doing over their updates of pacemakers for that.
Because of that risk analysis, the risk is that something goes wrong and someone
dies and that’s there’s really not a I can’t think of a strong way to mitigate that.
Maybe you could and if you can, then by all means, you know, like
a long time ago we talked about Tesla and I don’t want to open a can of worms talking about Tesla too much, but
they they do over the air updates and they have done over the air updates of things that are safety critical, like the suspension performance and the ride height.
You know, if they if they got that wrong, they could cause a lot of crashes.
So they I hope behind the scenes went through a process to verify that to a level where the risk was was low.
I think, you know, the can of worms is
their risk tolerance is higher than a lot of us are comfortable with.
But that’s that’s all I’ll say about them.
But you’re absolutely right.
I mean, not
over the air updates are rare in the medical device industry.
And and that makes you less agile as an organization because it is more
difficult to iterate on your product after it’s out in the market.
You have to release a new version.
And then now you’re dealing with a headache of configuration management.
Yeah. And also maybe you need to cut open your patient.
Right.
Which is kind of a bummer.
Right.
So that’s you know, that’s the kind of thing where
when you can’t do updates of your product in the field, you have to.
And I’m advocating to release a minimum viable product like you release a pacemaker.
It needs to work as a pacemaker.
And then maybe you the next year you introduce an improved version that
maybe a pacemaker is a bad example, but
it’s
a better pacemaker in whatever access that is.
And, you know, new patients are getting that.
And that’s based on feedback from the initial cohort of patients.
But they they still have a safe and effective product.
Maybe your new pacemaker has like implements new functionality,
has additional requirements that are based on market feedback.
Again, pacemaker may not be the best example, but we’ll run with it.
All right. That, I think, has been very, very interesting.
Dick, is there any.
Are there any questions you would like to to ask of Jeff?
Oh, no. Just for the second.
No, it was it was really gave me a good a good impression of for the
problems you have or the issues you have using HR, using DevOps in those kind of industries.
And I hardly and I hardly have no answer for that, because
my last question maybe you say hardware is that you have more longer sprint.
How much would you would you guess that a sprint in hardware development is?
That’s an excellent question.
Luca and I have discussed this previously, so I would say typical is several months.
So say, say, you know, you’re developing an embedded device and.
You discover a problem that requires
hardware fix, I would say typically you get a bunch of those problems to stack up
and then they’re all fixed because the the you know, this again, this is people
not leaning into the pain of what’s difficult.
They let a bunch of those things stack up for a few months and then they do a big
revision and that process of once we say, OK, these are the things we’re going to fix.
It’ll be four weeks minimum until the board is delivered.
But but it is so common to wait
on those kind of things for months.
And Luca has proposed to me in the past and I’m certainly intrigued by the idea
of having essentially a fixed hardware iteration where, yes, OK, whatever,
whatever time from you start the new schematic, which then leads to new layout,
which you order the boards and you have them delivered, whatever that iteration
time is becomes your hardware sprint or maybe something just barely bigger than
that, so that actually you have a new set of hardware coming out every four weeks.
Or six weeks, whatever it is.
I’m I have never seen that done.
I am intrigued by the possibility.
I think it could be really, really powerful.
Sounds good. Thank you.
You’re very welcome.
All right, Jeff, I think this is an excellent place to leave it.
Thank you so much for being on the show.
Where can listeners find more find more about you?
And this is something maybe you would like to brag about.
Sure. So so you can just go to my website.
It’s Jeff Gable dot com.
That’s J E F F G A B L E dot com.
And you can also find me on LinkedIn.
Obviously, all my content and
writings are in English,
not German.
But and you can also Luca, you and I obviously have a another
podcast called the Agile Embedded Podcast.
And if any of you out there are are interested in and how.
More learning more about how Agile techniques apply to the embedded world,
you can I definitely recommend listening to that podcast.
You can find it on any major podcast
publishers, Apple, Google, Spotify, et cetera.
So the Agile Embedded Podcast is what you would look for.
Awesome. Thanks so much, Jeff.
So again, thank you again for being on the show.
This was a really fun and interesting episode.
Thank you. Thank you so much.
Thanks, fellas.
Ciao.

Klicken Sie auf den unteren Button, um den Inhalt von podcasters.spotify.com zu laden.

Inhalt laden

Eine weitere Folge zum Thema Team Topologies. Wir haben Felix Kronlage-Dammers zu Gast. Mit ihm sprechen wir über seine Sicht auf das Buch Team Topologies und wie er das in seiner Praxis als COO bei gridscale anwenden konnte. Er skizziert unter anderem seine Herausforderungen und wie er die Ideen und Konzepte aus Team Topologies nutzen konnte, um einen verteilten Monolithen zu beherrschen. Natürlich beschreibt Felix auch, wie DevOps bei gridscale technisch und organisatorisch gestaltet ist. Er erzählt, was Winston Wolf aus Pulp Fiction mit gridscale und was Spotify mit Team Topologies zu tun hat. Zum Schluss erklären wir die Verbindung von Felix und Luca zu Dierks DevOps Mastermind Klub!

In dieser Episode des DevOps-Podcasts, moderiert von Luca Ingianni und Dierk Söllner, teilt Felix Kronlage-Dammers, COO von Gridscale, seine Einblicke in die Reise des Unternehmens hin zu Team Topologien. Die Diskussion vertieft sich in die technischen und organisatorischen Herausforderungen, die während des Wachstums von Gridscale auftraten, einschließlich ihres Übergangs von Monorepo zu Multirepo und der strategischen Bildung verschiedener Teams wie ‚Team Wolf‘. Sie erkunden die Feinheiten von DevOps, Automatisierung und wie das Lernen aus Fehlern ein wichtiger Teil ihrer Organisationskultur ist. Das Gespräch berührt auch das Spotify-Modell und seine Anwendbarkeit in verschiedenen organisatorischen Kontexten.

Inhalt

• Einführung in die Episode und die Gäste
• Hintergrund und Rolle von Felix Kronlage-Dammers bei Gridscale
• Definition und persönliche Ansichten zu DevOps
• Gridscales Übergang zu Team Topologien
• Herausforderungen bei organisatorischem Wachstum und Strukturveränderungen
• Diskussion über die Verwendung von Monorepos vs. Multirepos
• Rolle und Struktur von ‚Team Wolf‘ bei Gridscale
• Erkundung des Spotify-Modells und seiner Umsetzung
• Einblicke in das Lernen aus Fehlern und die Förderung einer Experimentierkultur
• Zukünftige Richtungen und offene Fragen zu Team Topologien

Shownotes:

Blogpost – Phoenix Project Online
Buch Empfehlung – An Elegant Puzzle: Systems of Engineering Management
Felix Blog
Felix bei Twitter
gridscale
DevOps Mastermind Klub

Transkript (automatisiert erstellt, wer Fehler findet darf sie behalten)

DevOps. Auf die Ohren und ins Hirn. Ein Podcast rund um DevOps. Von Luca Ingianni und Dierk Söllner.
Hallo und herzlich willkommen zu einer neuen Folge des Podcasts DevOps. Auf die Ohren und ins Hirn.
Gestaltet und produziert von Luca Ingianni und Dierk Söllner. Wir sind DevOps-Trainer und Coaches mit langjähriger Erfahrung.
DevOps umfasst für uns beide kulturelle, organisatorische und technische Aspekte.
Diese diskutieren wir mit Experten aus der Praxis oder in einer gemeinsamen Folge, wo nur Luca und ich etwas sprechen.
Wir freuen uns heute auf das Thema Gridscales Weg zu Team Topologies.
Zu Gast haben wir Felix Kronlage-Dammers.
Felix ist COO bei Gridscale und ich glaube es ist einfach besser, wenn sich Felix gleich selber vorstellt.
Felix, bitte sehr.
Moin und vielen Dank Dirk. Moin auch Luca.
Genau, ich freue mich hier zu sein. Zu meiner Person Felix.
Ich bin seit Herbst 2018 bei Gridscale.
Bin dort zusammen mit Hendrik Hasenkamp in der Geschäftsführung und verantworte dort den…
…technischen Bereich von Gridscale.
Der technische Bereich, das bedeutet im Prinzip Produktmanagement, Produktengineering und Betrieb unserer Plattform.
Vielleicht kurz was zu meiner Person.
Ich bin seit Ende der 90er in der Open-Source-IT-Szene unterwegs.
Hab für 15 Jahre lang die WideMine, ein Open-Source-IT-Infrastruktur-Dienstleister ursprünglich gegründet und bis Ende 2017 als Geschäftsführer begleitet.
Und hatte dort auch viele Berührungen.
Viele Berührungspunkte mit dem Thema DevOps, mit Automatisierung, mit Betrieb von großen Open-Source-Infrastruktur-Installationen und Ähnlichem.
Ich bin auf relativ vielen Baustellen unterwegs.
Ich bin nämlich auch noch im Vorstand der Open-Source-Business Alliance.
Also das Thema Open-Source treibt mich weiterhin um und bin dort viel aktiv.
Sehr schön.
Jetzt sind wir hier im DevOps-Podcast.
Und du hast ja eben selber auch schon gesagt…
…dass du dich auch mit dem Thema DevOps umtreibst.
Wir haben immer sehr viele schöne Definitionen, was DevOps ist.
Was ist denn für dich DevOps?
Ja, die Frage kommt natürlich nicht ganz überraschend, da ich ja tatsächlich ein Hörer von eurem Podcast auch bin.
Und so hatte ich ausgiebig Zeit, mich darauf vorzubereiten.
Jetzt könnte ich natürlich mit der ureigenen, langweiligen, finde ich, Definition der fünf Pfeiler kommen.
Also COIMS.
Culture, Automation, Lean, Measurement and Change.
Das will ich aber gar nicht.
Für mich setzt sich DevOps zusammen aus zwei Zitaten, die ich dafür mitgebracht habe.
Und das unterschreibt es auch schon ziemlich gut.
Das eine Zitat ist von Tim O’Reilly, dem Gründer des O’Reilly-Verlags.
Create more value than you capture.
Und das zweite Zitat ist von einem ehemaligen OpenBSD-Entwickler, Art Grabowski.
Only failures make success.
Work as experts.
Und diese zwei Zitate umfassen, also sind für mich im Prinzip zusammen die Symbiose, was für mich DevOps ausmacht.
Eben ein kultureller Mindset, der sich darüber definiert, dass man aus gemachten Fehlern lernt, diese möglichst iteriert, sodass ein besseres Ergebnis rauskommt.
Und das Bestreben danach ist, Mehrwerte zu erzeugen.
Create more value than you capture ist für mich im Prinzip der Inbegriff der Automatisierung.
Wenn ich etwas per Hand mache, mache ich es einmalig, vielleicht sehr gut, aber ich habe keinen konstanten Mehrwert geschaffen.
Mache ich eine Automatisierung, habe ich einen konstanten Mehrwert geschaffen, auf den andere wieder aufbauen können.
So, das wäre jetzt so meine Definition von DevOps.
Cool. Also ist auf jeden Fall was Neues.
Also auch zwei tolle Zitate mit dabei.
Jetzt haben wir den Titel schon angesprochen.
Gridskates Weg zu Team Topology.
Du hast ein bisschen was zu Gridscale gesagt.
Was macht denn ein COO, das ist ja deine Position bei Gridscale, was macht ein COO bei Gridscale, was macht Gridscale auch im Zusammenhang mit dem, was wir als Thema haben, Team Topologies?
Gridscale ist ein Softwarehersteller für einen vollautomatisierten Virtualisierungsdeck für das Rechenzentrum.
Das heißt, wir automatisieren und virtualisieren den Betrieb von Rechenzentren.
Das, was man auf den ersten Blick von Gridscale sieht, wenn man auf unsere Webseite kommt, ist ein Public-Cloud-Angebot.
Das Public-Cloud-Angebot realisieren wir mittels unseres eigenen Software-Stacks, den wir aber auch mittlerweile in die Data Center der Kunden bringen und dort für den Kunden betreiben.
Das heißt, anders als zum Beispiel VMware oder Nutanix, ist bei Gridscale der Betrieb, der Plattform für den Kunden.
Das heißt, dass wir tatsächlich uns als Softwarehersteller verstehen und auch mit entsprechenden Methoden bei Gridscale vorgehen, um die Dinge zu entwickeln.
Anders als zum Beispiel ein reiner Public-Cloud-Hoster, der halt nur auf den Betrieb seiner eigenen Plattform achtet, gehen wir tatsächlich einen Schritt weiter und haben überall auch Softwareentwicklungsparadigmen etabliert.
Zu meiner Rolle, du hattest mich gefragt, was ein COO macht.
Ja.
Also, es ist so, dass die Geschäftsbereiche, die bei mir liegen, ist eben Produktmanagement, Engineering und eben der Betrieb der Plattform.
Das ist allein schon deswegen so, damit Ressourcen, die innerhalb der Entwicklung und innerhalb des Betriebes sind, möglichst miteinander verzahnt sind.
Weil das natürlich auch ermöglicht, dass dort tatsächlich eben keine Silos entstehen, sondern miteinander integrativ gearbeitet wird.
Genau. Bei mir eben liegt das auch das Produktmanagement, also das Sicherstellen.
Genau. Bei mir liegt das auch das Produktmanagement, also das Sicherstellen.
Genau. Bei mir liegt das auch das Produktmanagement, also das Sicherstellen.
Okay. Das heißt, du kommst wirklich aus der Praxis, du weißt, was DevOps dann heißt auch, was das konkret für dich auch bedeutet.
Wie bist du denn auf das Buch gekommen von Team Topologies?
Vielleicht kannst du dazu nochmal ein bisschen was erzählen.
Und vor allen Dingen, warum hat es dich so begeistert, wie es auch Luca und mich begeistert hat?
Ja.
Da habe ich tatsächlich an der Stelle, muss ich zugeben,
eine gehende Leere im Kopf, weil ich nicht mehr genau weiß, wie ich auf das Buch gekommen bin.
Also entweder ich habe es bei IT Revolution auf der Webseite gesehen,
weil ich im Prinzip einen Großteil deren Portfolio mittlerweile gelesen habe und tatsächlich auf die Seite gestoßen bin.
Oder ich habe mit irgendeinem Kollegen darüber gesprochen und bin da mal hochgepoppt.
Ich weiß nur, dass ich es tatsächlich bestellt habe und dann in ziemlich kurzer Zeit sehr intensiv durchgekommen bin.
Und durchgearbeitet habe und dann festgestellt habe, dass das eines von den Büchern ist, wo, wenn man mit einem Textmarker arbeitet, im Prinzip die Hälfte des Buches gelte.
Also das war tatsächlich dann so.
Und mittlerweile habe ich es dann tatsächlich mehrfach auch durchgearbeitet, weil mich und ich glaube, das, was mich als allererstes getriggert hat bei dem Buch, war eben die Betrachtung, also Convays Law und das Inverse Convey Maneuver.
Und eben dieser Gedanke, okay, hey, wir haben hier eine Organisationsstruktur, wir haben hier eine Softwarearchitektur und lass uns das einmal von einer Seite auch betrachten, was das für Zusammenhänge hat.
Das fand ich sehr spannend und das hat mich jetzt sofort getriggert.
Okay, ja, spannend. Das war ja auch das, was mich so an dem Buch irgendwie, was mich da direkt angesprochen hat, weil ich finde, dass es einem, oder zumindest für mich war das so,
dass das endlich in Worte gefasst wurde.
Und das hat eine Sache, die mir irgendwie schon gedämmert war im Laufe der Jahre, aber wo ich halt irgendwie noch auch keinen Begriff dafür hatte.
Kannst du da irgendwie was erzählen, wo du besonders gesagt hast, ah, Donnerwetter, das ist mir doch irgendwie vorgestern begegnet oder vorletztes Jahr begegnet oder sowas?
Naja, also die Compiler-Geschichte, also das ist ja dieses Standardbeispiel, was ja in dem Buch…
…kommt, wo ich, was natürlich für jemanden wie mich, der relativ tief in der Technik ist, ja sofort und augenscheinlich war.
Und ich hatte aber das Gefühl, als ich diesen Teil vom Buch gelesen habe, dass ich im Prinzip hier saß und mir dachte, hm, im Prinzip ist das die Erklärung für das, was ich das letzte, vierte Jahr immer wieder versucht habe, an der einen oder anderen Stelle auch zu greifen.
Und für mich…
…sichtbarer zu machen, warum gewisse Dinge so sind, wie sie sind. Und so.
Mhm. Aber trotzdem, ich wäre so gespannt, ob du da irgendwie ein bisschen ein konkretes Beispiel, ob dir da was einfallen würde.
Also ich, als ich zu Gritzke gestoßen bin, also ich bin im Oktober 2018 bei Gritzke an Bord gekommen.
Also ich war, und ich war Mitarbeiter 21.
Und ab dann ging die Reise unseres Wachstums nochmal relativ gut weiter, weil wir dann innerhalb von anderthalb, zwei Jahren in Richtung 70 Mitarbeiter gesprungen sind.
Das heißt, wir haben dann da einen ziemlichen Shift gemacht, haben in dem Jahr vorher auch schon mal ein gutes Wachstum hingelegt.
Und was man da tatsächlich gesehen hat, ist, dass im Prinzip ab Mitte 2018 bis…
…anfang 2020, also so Ende 2019, durch den Wachstum in den Teams sich natürlich die Art und Weise, wie wir bei uns mit dem Arbeitsmittel, dem Quellcode umgehen und wie wir auch auf die Architektur blicken, durchaus verändert hat.
Und als ich bei Gritzke reingekommen bin, war es im Prinzip so, dass das Ideal…
…einmal wird eigentlich eine Microservice-Architektur der verschiedenen Komponenten ist.
Und was im Prinzip, wenn man guckt, es gibt einen sehr, sehr guten Blogpost von Kelsey Hightower von Google, der über den verteilten Monolithen geht.
Und also ein verteilter Monolith, also ein Monolith, was ist eine Microservice-Architektur, ist ja erstmal, dass in einer Microservice-Architektur hast du viele, viele kleine Komponenten,
…den du am Stück irgendwo hinschmeißt, startest und läufst.
Und der verteilte Monolith ist im Prinzip, du nimmst diesen Monolithen, baust ihn in eine Microservice-Architektur um, bist aber keine wirkliche Microservice-Architektur,
…sondern hast immer noch das…
…und die Herausforderung, dass du relativ viel Programmcode am Stück irgendwo hindeployen musst, damit es halt ordentlich funktioniert.
Und das ist im Prinzip etwas, wo sich dann sehr schnell auf die Abhängigkeit oder die Zusammenhänge zur Unternehmensorganisation auch zeigen.
Und ein gutes Beispiel, was ich dafür mitgebracht habe, ist, dass wir…
…also von der Architektur her haben wir verschiedene Teams, die sich um verschiedene Schichten bei uns kümmern.
Und ein guter Teil unserer inneren Schicht ist das, was seinerzeit bei uns tatsächlich das Team Python genannt wurde, weil eben ein großer Teil davon von dem Python entwickelt wurde.
Und dort gab es, ich meine Mitte 2019, dass wir das Team aufgeteilt haben in zwei Teams, nämlich ein Team, was unsere sogenannten Core-Services,
…bereitstellt, gewisse APIs, und ein Team, das nennen wir Smart-Services, was zum Beispiel unsere Datenbank-Dienste, also unsere Platform-Services, bereitstellt.
Und ursprünglich haben diese beiden Teams, waren in einem Team zusammen, das alles lebt in einem Monorepo und ist dadurch halt miteinander relativ verzahnt.
Und man könnte an der einen oder anderen Stelle tatsächlich auch sagen, dass es halt…
…also ist tatsächlich zu sehr verzahnt.
Und, ja, Dirk?
Ich habe gerade mal gedacht, Mensch, ich spiele mal jetzt denjenigen, der die Frage stellt, was ist ein Monorepo?
Sehr gut, danke.
Pardon, genau, da bin ich dann auch schon an der Stelle zu sehr Techniker.
Monorepo ist eine Art und Weise, den Quellcode zu organisieren.
…zu organisieren.
…zu organisieren.
Also ein Repository ist eine Organisationseinheit, in der du im Prinzip zusammenhängenden Quellcode organisieren kannst, mittels einer Versionskontrolle.
Also ein Versionskontrollmechanismus ist ja, dass du jede Änderung eincheckst und darüber nachverfolgbar machst.
Das heißt, darüber kannst du sehen, was ist der Unterschied zwischen einer Version und der nächsten Version im Quellcode.
Und da gibt es eben den Ansatz des Monorepos.
Alles ist in einem Repo und kann…
…dadurch sehr zusammenhängend deployed werden.
Oder du hast halt Multirepo, also pro Einzel deploybarer Komponente tatsächlich ein einzelnes Repository.
Und wir kamen ursprünglich von einer Multirepo-Welt, sind dann in eine Monorepo-Welt gewechselt und haben tatsächlich mittlerweile festgestellt, dass das…
…und das ist…
…das hat sich sehr gut dargestellt anhand dieser Teams, die wir dann wieder aufgeteilt haben, dass uns das an der Stelle tatsächlich auf die Füße fällt.
Wo man tatsächlich merkt, dass eben die Organisation und die Organisationseinheiten und das, wie andere Dinge organisiert sind, eben der Quellcode, die Deploy-Mechanismen, die ICD-Pipelines, Logik, Datenhaltung, dass das alles miteinander zu tun hat…
…und sich auch gegenseitig…
…sich tatsächlich sehr bedingt.
Weil jetzt auf einmal nämlich das eine Team, wenn es etwas ändern will, im gleichen Repo wie das andere Team arbeitet und nicht mehr unabhängig voneinander deployen kann.
Das heißt, das, was ja die Kernaussage ist oder Kernaussagen von Team Topologies, dass Architektur und Organisation zusammenhängen.
Und das habt ihr dann im Prinzip ja auch gebergt.
Das heißt, du hast ja die verschiedenen Schritte, die verschiedenen Wege aufgezeigt.
Wenn man jetzt ganz einfach schauen würde, würde man sagen, Monorepo ist gut, Monorepo ist schlecht.
Und du würdest jetzt sagen, es kommt darauf an, wie die Organisation drumherum aussieht.
Total.
Also total hängt es davon ab, wie die Organisation drumherum aussieht, wie die Software an sich strukturiert ist, ob die Software einem ermöglicht, Deployments auch aus einem Monorepo heraus singulärt zu machen.
Also das ist schon sehr individuell.
Und tatsächlich…
Und tatsächlich ist das auch eines, glaube ich, der heiligen Graal-Themen der letzten Jahre, wo man auch ganz viel im Netz so findet.
Monorepo oder nicht Monorepo.
Und tatsächlich, also für uns war ganz spannend, weil ich tatsächlich, also kurz nachdem ich angefangen habe, war eben der Switch auf Monorepo.
Das wurde halt auch durchaus unterschiedlich betrachtet.
Und mittlerweile stellt sich halt heraus, okay.
Nicht der beste Schuss.
Aber auch das, und da sind wir jetzt so ein bisschen bei dem Only Failures Makers Experts, auch das ist halt wichtig, dass so etwas in einer Organisation A möglich ist und B, dass man sich auch einsteht, dass halt nicht jeder Schuss ist unbedingt ein Treffer, aber wenn man den Schuss nicht macht, wird man es halt auch nicht herausfinden.
Das heißt also an der einen oder anderen Stelle ist es halt auch wichtig, Dinge einfach mal auszuschauen.
Ein paar Meter zu probieren, ein paar Meter zu laufen und zu gucken, wie weit kommt man damit und nicht sofort die Idee oder die Diskussion im Keim erstickt.
Würdest du, wenn ich das so höre, und wir haben ja auch anderweitig Kontakt, wenn ich das so höre, scheint mir Gridscale ein ziemlich modernes Unternehmen zu sein.
Das, was du gerade sagst, das ist ja für mich sehr, sehr modern.
Fehler machen aus Fehlern lernen.
Würdest du Gridscale als ein modernes Unternehmen bezeichnen und ist in dem Zuge dann DevOps?
Vielleicht auch für euch dann ein Selbstläufer?
Das erste Ja, das zweite Nein.
Okay.
Also wir hatten ja im Vorfeld gesagt, ich mache keine Werbung.
Aber tatsächlich muss, also eben mal nicht aus der technischen Brille, sondern erstmal aus der reinen Arbeitgeberbrille und da an der Stelle bin ich halt dann in meiner Rolle Arbeitgeber,
ist es tatsächlich so, dass Gridscale ein sehr modernes Unternehmen ist und dass die Kultur, die wir bei Gridscale haben, was das Machen, das Vorausfordern von Fehlern extrem toll ist.
Also wir ermutigen Mitarbeiter, Dinge auszuprobieren, dass Häufigkeit zitiert ist, dies fail fast.
Learn fast.
Ich finde es, ich mag den Satz gar nicht so sehr, sondern ich finde es einfach wichtig, dass Mitarbeiter in allen Bereichen dafür die Chance haben, Sachen auszuprobieren, eben ein paar Meter zu laufen und es dann tatsächlich auch eben eigentlich kein krasser Fauxpas ist, wenn es halt nicht funktioniert, sondern es einfach, hey, gucken wir uns an, ziehen Learning raus und dann laufen wir weiter.
Und so ist halt unsere Kultur insbesondere, weil wir halt auch ein Plattformbetreiber natürlich sind.
Es ist halt so, es gibt…
In jedem technischen System gibt es Fehler und eine der wichtigen Sachen, die wir einfach bei uns etabliert haben, ist ein sehr sauberer Postmortem-Prozess.
Also das tatsächlich, wenn ein Fehler auf der Plattform passiert, wenn ein Bug mit Customer Impact auftritt, dass wir einen Postmortem machen und dass dieser Postmortem aber sehr sauber gemacht wird mit einer guten Root-Course-Analysis, Stichwort Five Whys, also tatsächlich dies durchgehen und tatsächlich bis auf den Boden der…
Der Ursache kommen, um daraus dann eben das maximale, den maximalen Lerneffekt zu haben.
Und dann ist im Prinzip jeder Incident, den man hat, auf eine gewisse Art und Weise, so sehr er an einer anderen Stelle wehtut, ist er aber sehr viel wert, weil man den Fehler dann nicht nochmal machen muss.
Und das ist natürlich ein sehr hohes Gut, eine solche Organisation zu haben, die ihm das ermöglicht.
Ist deine Frage, auf die ich dann Nein gesagt habe, ist DevOps ein Selbstläufer?
Nein.
Nein.
Und ich kann dir nicht mal genau sagen, warum eigentlich nicht.
Ich stelle jetzt einfach mal die These auf und da könnt ihr gerne mir jetzt widersprechen.
Ich glaube, es wird kaum eine Organisation geben, wo DevOps tatsächlich ein Selbstläufer ist.
Einfach, du sagst ja nicht, oh, wir machen DevOps.
Das ist jetzt wie Mensch ärgerlich nicht.
Jeder kennt, es gibt halt so ein Basistregelset und das ist es.
Sondern du bringst…
Du bringst fünf oder zehn, zwanzig Menschen zusammen und guckst dir an, okay, wir sind hier, wir wollen da hinten hin und wie schaffen wir das?
Und dann hast du auf diesem, wenn du sagst, okay, ich entscheide mich für ein Werkzeug, was ich einsetze, das Werkzeug könnte zum Beispiel sein eine DevOps-Methodik oder ein DevOps-Mindset, sagen wir mal ein DevOps-Mindset,
dann werden die fünf, zehn oder zwanzig Menschen ja immer noch teilweise unterschiedliche Dinge darüber verstehen.
Allein deswegen ist es kein Selbstläufer.
Und das heißt, da hast du dann natürlich das, was ja elementar wichtig ist, damit man überhaupt vorwärtskommt, nämlich eine gewisse Reibung aneinander.
Also Konflikte sind ja wichtig, weil sonst kommt man ja nicht vorwärts.
Es geht ja immer nur darum, wie man diese Konflikte dann auch hat.
Und da ist, glaube ich, selten ein wirklicher Selbstläufer.
Aber ihr könnt mir gerne widersprechen.
Ihr seid die, die an ganz viele Unternehmen reingucken.
Dort sehen.
Naja, wenn wir jetzt hier der Verkäufer wären unserer Trainingsangebote, dann würden wir sagen, bucht ein Training vor uns.
Mit euch ist es ein Selbstläufer?
Ja, ja, nein.
Aber nein, der Podcast, der soll ja wirklich die Wahrheit berichten und soll wirklich authentisch sein.
Also insofern ist das für mich nachvollziehbar.
Also ich sehe das auch.
Es ist auch immer die Frage, was ist DevOps?
Also ich habe so einen Kontakt vor Augen von jemandem, der aus der ganz klassischen Welt kommt.
Und der hat sich jahrelang gegen meine Versuche gesperrt.
Ihm so ein bisschen.
Zu unterstützen mit Agilität, mit DevOps und dann war, hatten wir so ein halbes Jahr Funkstelle und dann haben wir telefoniert und meinte, hey, wir machen jetzt auch DevOps.
Ja, und da habe ich sofort gewusst, die machen nicht DevOps, weil das kann nicht sein, dass dieser Wechsel dann vor einem halben Jahr stattfindet.
Aber auch das, was du sagtest, zurückgezogen.
Du hast ja eben gesagt, es ist kein Selbstläufer.
Und wenn ich DevOps definieren würde oder beschreiben würde, gibt es da verschiedene Punkte.
Das, was du sagtest, Kalms, also Automation, Lean, Management und so weiter.
Also es gibt zwei.
Es gibt so viele Bestandteile, so viele Stellschrauben für DevOps, dass ich sagen würde, ihr beherrscht vielleicht das Thema Automation.
Ihr beherrscht vielleicht auch das Thema Lean.
Aber ein paar andere Dinge beherrscht ihr nicht und müsst da ein bisschen nacharbeiten.
Ja, also wir sind hier ja auch so ein bisschen, um aus dem Nähkästchen zu plaudern.
Und wir, Dirk, also wir haben uns ja letztes Jahr, Anfang letztes Jahr irgendwann kennengelernt.
Können wir ruhig erzählen, warum und wieso, ne?
Ja, wir können uns bei jemandem ganz netten bedanken, der uns zusammengebracht hat.
Genau, ein gemeinsamer Freund hat uns zusammengebracht, weil Dirk das Phoenix Project Online als Spiel mit übersetzt hat.
Oder als Online-Seminar, ist das Online-Seminar?
Online, also eigentlich ist es eine Online-Simulation.
Online-Simulation übersetzt hat und Testläufer ja brauchte, die das mit ihm einmal durchspielen.
Und das habe ich dann mit Dirk und ein paar anderen durchgespielt.
War davon so begeistert, dass ich ja Vorschläge habe, das bei uns mit den technischen Teamleads zu machen.
Und wollen wir Phoenix Project kurz erklären oder kennt der geneigte Hörer von euch das?
Der geneigte Hörer sollte das kennen.
Sag ich jetzt mal so, wir können ja in die Shownotes oder in die Beschreibung einfach einen Link reinpacken, was dahinter steckt.
Es sei denn, du bist so begeistert, dass du es immer noch wieder erzählen willst.
Nein, wir können einfach auf meinen Blog-Post dazu verlinken, den ich auch zu der Simulation geschrieben habe.
Perfekt, machen wir.
Naja, auf jeden Fall habe ich das dann ja mit dir und unseren Teamleads auch nochmal durchgespielt als ein Tages- oder Halbtages-Simulations-Workshop.
Und du wirst dich ja auch daran erinnern, dass da bei uns auch Leute dabei waren, die gesagt haben, puh, wow, das ist ja mal was.
Und tatsächlich hat das hier und dort auch nochmal einfach wirklich, glaube ich, den Blick geschärft.
Beziehungsweise die Blickrichtung verändert oder einen anderen Blickwinkel ermöglicht.
Also Stichwort zum Beispiel, du hast gesagt Automatisierung.
Automatisierung ist klar, da haben wir einen sehr starken Fokus drauf.
Wo wir aber auch tatsächlich hinwandern, ist, dass wir tatsächlich die Möglichkeit haben, x-mal am Tag unseren kompletten Stack im Prinzip zu deployen.
Und so einen kompletten Stack x-mal am Tag deployfähig zu machen.
Das ist halt auch ein Stück Weg.
Und da sind zum Beispiel Sachen, die dann schon in der Praxis wieder auftauchen, wo klar ist, okay, da machen wir gut Wegstrecke.
Aber da ist halt auch noch was.
Ja, okay.
Also ich möchte da eine Sache aufgreifen, die du vorhin gesagt hast, als es ging um die Schwierigkeiten von DevOps.
Ich glaube, dass…
DevOps deswegen kein Selbstläufer ist und deswegen nicht nur sich schwierig anfühlt, sondern auch tatsächlich ehrlich schwierig ist, weil es nicht davor zurückschreckt, sich auch um die menschlichen Seiten dieser ganzen technologischen Entwicklungen zu kümmern, mit denen wir uns befassen.
Es geht eben nicht nur um Monorepos, sondern es geht immer auch um die Leute, die die Monorepos irgendwie benutzen und betreiben.
Und es geht nicht nur um eine CI-Pipeline.
Sondern es geht auch um die Leute, die eine CI-Pipeline benutzen und Feedback von dieser CI-Pipeline bekommen.
Und so weiter.
Ja, richtig.
Das führt mich natürlich, wo du den Fokus nochmal auf die Menschen auch bringst, zu einer Sache, die natürlich auf dieser Wegstrecke…
Also ich bin jetzt seit 2018 bei Gridscale dabei.
Gridscale wurde 2014 gegründet.
2015 Markteintritt.
Das heißt also, da waren vorher schon ein paar Jahre vorher, wo viel passiert ist.
Aber was natürlich…
Jetzt haben wir die Startup-Phase ja auch gut hinter uns gelassen.
Aber was natürlich schon da ist, oder was natürlich auch in jedem Startup passiert, ist, dass du ja die Leser von The Phoenix Project kennst.
Die Rolle des Brand.
Also eben…
Also eine wichtige Sache, die in den Lebenszyklus eines Startups kommt, ist, dass du deine Brands identifizierst.
Oder deinen Brand.
Wer ist nochmal ein Brand?
Ein Brand ist die Person, zu der alle hingehen, wenn sie etwas wollen, wenn sie ein Problem haben, wenn ein Kunde nicht klarkommt.
Egal was.
Es gibt genau die eine Person.
Und die wird es lösen.
Und nur die kann es lösen.
Weil die weiß alles und kann alles.
Die weiß alles.
Die kann alles.
Und du kannst sicher sein.
Nach spätestens 24 Monaten…
Nach spätestens 24 Monaten ist Brand durch.
Wenn er überhaupt die 24 Monate dann noch schafft.
Das heißt also, in jedem Lebenszyklus eines Startups oder eines Technologie-Startups wirst du das haben.
Und was natürlich…
Es gibt da noch eine andere Formulierung aus einem anderen sehr guten Buch.
Das ist das Inelegent Puzzle Systems of Engineering Management von Will Larsen.
Sollten wir auch in die Show-Notes packen.
Exzellentes Buch.
Das hat ein Kapitel.
Das heißt Kill Your Hero Programmer.
Und da geht es halt auch genau darum, dass es wichtig ist, dass man auf dieser Reise,
wenn man ein skalierendes, wachsendes Unternehmen aufbauen will, dass es wichtig ist, dass du
verschiedene Leute in ihrer Entwicklung förderst.
Und aber auch sicherstellst, dass du eben nicht nur diesen ein oder zwei Hero Programmer
hast.
Weil das im Prinzip zwar an der einen Stelle sehr viel Geschwindigkeit erzeugt, die Organisation
drumherum aber lähmt.
Weil wenn der eine Hero Programmer komplett voranprescht, dann hat der Rest der Organisation
drumherum überhaupt keine Chance hinterherzukommen oder gemeinsam an einer Architektur zu arbeiten
etc.
pp.
Und genau.
Also das sind halt schon Herausforderungen, die ich denke mal jedes Startup kennen wird,
die dann irgendwann Geschwindigkeit aufnehmen.
Weil es natürlich, es ist extrem verlockend, jemanden wie Brent immer wieder anzusprechen,
weil das ist ja die instantane Gratifikation für dich, wenn du weißt, ich gehe dahin,
der löst mein Problem.
Aber es ist halt sehr kurzfristig dann gedacht.
Aber nicht desto weniger ist es verlockend, gerade wenn du im Prinzip Dinge sehr schnell
erreichen willst.
Und da ist es wichtig, dass man, glaube ich, am gewissen Punkt erkennt, okay, jetzt sind
wir an dem Punkt.
Wo es wichtiger ist, mittelfristiger und nicht mehr diesen kurzfristigen Blick zu haben
und dann zu schauen, dass man eben Brent identifiziert und ermöglicht, in eine andere
Rolle zu wechseln und das Wissen dann tatsächlich weiter zu verteilen.
Okay.
Wir haben ja im Titel Team Topologies drin.
Jetzt hast du viele tolle Sachen erzählt, die aber nicht alle sich auf Team Topologies
beziehen.
Wenn ich es im Prinzip so einschätze.
Können wir nochmal ein bisschen auf ein paar Begriffe eingehen?
Ich habe zum Beispiel vorhin was von dem Reverse Conveys Manoeuvre erzählt.
Ich glaube, das wäre nochmal interessant, was du da bei Gridscale erlebt hast dazu.
Ja.
Tatsächlich, als ich mich näher mit der Thematik Conveys Law, Reverse Conveys oder Inverse
Conveys Manoeuvre beschäftige, habe ich dann tatsächlich mich hier mal an den Schreibtisch
gesetzt und mich dann mit ein paar Kollegen dazu unterhalten und tatsächlich angefangen,
unsere mittlerweile ja tatsächlich auch verhältnismäßig komplexe Architektur einfach tatsächlich mal
aufzumalen.
Und der erste Schritt, den ich tatsächlich gemacht habe, war, dass ich von den technischen
Teams, die wir haben, jedes Team gebeten habe.
Dass sie mal aus ihrer Sicht die Architektur aufmalen.
Also tatsächlich, also wir haben ja im Prinzip einen, kann ich auch kurz jetzt einmal darauf
eingehen, damit man es so ein bisschen greifbar hat.
Also wir haben eben diese Core Services, die ich vorhin schon genannt habe, die APIs bereitstellen.
Wir haben die Smart Services, die unsere Plattformdienste bereitstellen.
Dann haben wir im Prinzip eine Middleware, wo sehr viel Billing etc.
pp.
läuft.
Und dann haben wir ein Frontend-Team.
Und das Frontend-Team bedient im Prinzip mit unseren Panels die APIs, die von anderen bereitgestellt
werden.
Und neben diesen Teams haben wir dann auch noch zwei weitere Teams.
Im Prinzip ein Team, was sich um Operations, Data Center etc.
kümmert.
Und ein Team, Team Wolf, da kann ich später noch so ein bisschen was zu erzählen.
Das ist aber auch ein technisches Team, was halt auch Entwicklungsarbeit leistet.
Ich habe jedes Team gebeten, die Architektur aufzumalen.
Und das war tatsächlich der erste Schritt, wie ich mich dem genähert habe, weil darüber
überhaupt mal sichtbar wurde, wie eigentlich ein Frontend-Team unsere Architektur sieht
versus wie jemand, der bei uns in den Core Services arbeitet, also dafür zuständig ist,
Provisionierung von virtuellen Maschinen und ähnliches durchzuführen.
Wie der auf die Architektur blickt.
Und das haben wir dann tatsächlich mal gegeneinander gehalten und auch miteinander abgeglichen.
Und daraus habe ich dann tatsächlich erst einmal angefangen, über die Teamstruktur nachzudenken
und dann zu identifizieren, was für Teamarten haben wir eigentlich.
Also Team Topologies geht ja erstmal von vier Teamarten aus.
Wir haben im Prinzip die Streamaligned Teams.
Wir haben die Platform Teams.
Wir haben Complicated Subsystem Teams.
Und die sogenannten Enabling Teams.
Das sind ja die vier Teamarten, die meine ich auch schon in einer der letzten Folgen hervorgestellt habe.
Und dann bin ich beigegangen und habe halt erstmal geschaut, okay, wo fällt es mir einfach,
das tatsächlich zuzubehalten, also tatsächlich so ein Label ranzukleben.
Also ist das Team Streamaligned oder nicht?
Und für mich war es der erste Schritt,
war der erste Indikator, oh, da muss man näher hingucken, wo es mir nicht leicht fiel.
Also niemand, wo ich auf ein Team geblickt habe und gefragt habe, okay, Streamaligned ist es nicht.
Platform, ja, wäre schön, aber auch nicht?
Okay, aber was, Complicated Subsystem Team?
Nee, auch nicht.
Und da war dann klar, okay, da muss man dann vielleicht mal genauer schauen.
Und das war dann tatsächlich an der Stelle, wo, ja, ich bezeichne ja gerne Team Topologies tatsächlich als Framework oder als Werkzeug,
wo tatsächlich dann das Team Topologies eben wie so ein Werkzeugkasten zum Einsatz kommt,
um damit eher einfach dann auch erstmal zu helfen, Sachen sichtbarer zu machen und greifbar zu machen,
dass man da eventuell weiter reinschaut.
Und ein Verständnis dafür zu entwickeln.
Genau.
Du hast ja im Prinzip genau diese vier Teamarten genommen und hast geguckt, ist das so eins?
Also ist das Team eins dieser vier Teamarten?
Plus natürlich, dass das Team Topologies ja auch ein Verständnis davon hat, wie welche Teams miteinander interagieren, also zusammenarbeiten.
Und wenn man das dann gegeneinander hält und feststellt, hm, das passt aber eventuell gar nicht zu dem,
was in der Realität stattfindet oder wie die Realität aussieht, ist das auch natürlich ein Indikator,
dass man da einfach mal näher reinschaut.
Ja, aber das ist, da sagst du so im Vorbeigehen ganz irgendwie lässig, eine ganz, ganz wichtige Sache.
Nämlich etwas, was glaube ich viel zu häufig ausbleibt, dass die Leute dann, so wie du das jetzt gemacht hast,
sich irgendwie so ihre Teams zurechtlegen und sagen, ja, das da, ist das jetzt ein Streamer-Line-Team oder nicht oder so.
Und es gibt ganz viele, die dann einfach, glaube ich, dabei verharren und sagen so, das muss jetzt irgendwie in dieses Schema reingepresst werden.
Das ist das Team, das ich habe, wird schon Streamer-Line sein.
Aber was du gemacht hast, ist eben genau das ganz Tolle dabei.
Nämlich zu fragen so, Moment, wenn mir das schwerfällt, dann sagt mir das was.
Dann, wenn der Schuh drückt, dann ist es wohl nicht der Richtige.
Und das ist nicht zu unterschätzen, glaube ich.
Genau, und ich hatte ja gerade schon eins der Teams erwähnt, wo ich sagte, da kann ich dann nochmal was zu sagen.
Das Team Wolf.
Das Team Wolf, als wir das ursprünglich aufgemacht haben, das Team, also das war eine,
es entsprang einer Diskussion, die ich mit einem Freund aus der Schweiz hatte.
Und wir saßen in einem Hotel in Berlin zusammen und haben uns so ein bisschen überlegt,
Und wir saßen in einem Hotel in Berlin zusammen und haben uns so ein bisschen überlegt,
über eben Unternehmensorganisation, Struktur etc. pp. unterhalten.
über eben Unternehmensorganisation, Struktur etc. pp. unterhalten.
Und das Resümee daraus war, dass wir im Prinzip beide sagten, eigentlich braucht jedes technische Unternehmen,
braucht ein Team Wolf.
Ein Team Wolf, benannt nach Vincent Wolf aus PathFiction, dem Problemlöser.
Wo klar ist, okay, dieses Team, das löst einfach nur Probleme.
Und wenn man zum Beispiel ein Unternehmen hat, was Software herstellt,
Und wenn man zum Beispiel ein Unternehmen hat, was Software herstellt,
dann muss man in dieser Organisation immer wieder Aufgaben haben,
dann muss man in dieser Organisation immer wieder Aufgaben haben,
die mit dem Kernprodukt überhaupt nichts zu tun haben.
Scrape mir mal bitte die Daten von diesen Webseiten,
oder transformiere mir diese Daten von A nach B,
oder schau doch mal, ob du nicht in der Datenbank ein paar QBs machen kannst,
dass wir ein paar Analysen fahren können.
Also Aufgaben, die zwar in den Kosmos des Unternehmens passen,
die aber eben nicht zur Kernproduktentwicklung gehören.
die aber eben nicht zur Kernproduktentwicklung gehören.
Und was ja dann passiert ist, dass du zu einem Produktentwickler gehst
und sagst, hey, du machst ja eh gerade an der Datenbank rum,
kannst du mir auch noch mal die drei Query schreiben?
Oder kannst du mir noch mal das analysieren?
Oh, du kannst die Programmiersprache XY,
Scrape mir doch mal die Webseite da.
Und damit findet aber ja eine Defokussierung statt.
Das heißt also, im Prinzip Entwickler, die am Kernprodukt arbeiten, werden defokussiert.
Und das ist ja eines der Sachen, die dafür Sorge tragen,
dass Entwicklungsprozesse dann langsamer werden,
weil Leute ständig defokussiert werden.
Weil Leute ständig defokussiert werden.
Und ein solches Problemlöserteam, die Idee ist,
dass dabei dann eigentlich dort Sachen landen,
die sonst andere defokussieren würden.
Und das ist das Team Wolf.
Damit sind wir dann auch losgelaufen.
Tatsächlich erfordert natürlich so ein Team Wolf,
wie es da angedacht war, relativ viel Disziplin.
Nämlich, dass man dann nicht anfängt,
oh, wir haben da einen Entwickler,
lass uns die auch mal für Produktentwicklung auch benutzen.
Und das ist natürlich was,
wo wir,
wo man dann auch sich selber gegenüber,
glaube ich, an der einen oder anderen Stelle dann ehrlich sein muss.
Wo man tatsächlich dann durchaus aus dem,
aus dem im Alltag dann eventuell,
wenn man nicht ganz so konsequent ist,
durchaus da dann,
durchaus dann auch mal reingeht
und daraus Produktentwicklung heraus machen lässt.
Oder also bei uns ist zum Beispiel das Team Wolf,
sind die, die unser Ecosystem bauen.
Also Terraform Provider oder unser Go SDK
und andere Libraries werden halt dort gebaut.
Das sind wichtige Teile,
aber halt eben nicht Kernbestandteil der Produktentwicklung.
Ja, das finde ich spannend.
Das ist, das ist auch so ein Team,
von dem ich das Gefühl habe,
es sollte existieren,
aber das ist so ein Kunstgriff,
den glaube ich viele,
den Schritt gehen viele glaube ich nicht.
Sondern sie verharren dann in dem,
was du beschrieben hast.
Ja, genau.
Und jetzt nehmen wir mal,
jetzt nehmen wir nochmal Team Topologies
und jetzt kannst du, Luca,
mir mal sagen,
wo bei den Team Topologies passt dieses Team rein?
Es ist nicht Steam,
es ist nicht Stream-aligned,
es ist keine Plattform,
also es baut ja keine,
es ist ja nicht X-as-a-Service,
außer vielleicht Human Resource X-as-a-Service,
also Human Resource X-as-a-Service.
Es ist auch kein Complicated SAP System Team.
Und wenn ich ehrlich bin,
nach der strengen Definition ist es auch kein Enabling Team.
Das ist jetzt insofern gemein,
als ich dir eigentlich diese Frage stellen wollte,
aber sei es drum.
Ich hatte die extra mitgebracht.
Ich finde das gut.
Jetzt bettelt ihr euch mal hier.
Genau.
Nee, aber ich meine,
die Frage ist einerseits spannend,
oder sie ist eigentlich auf jeden Fall spannend,
sie ist nur aus zwei verschiedenen Perspektiven spannend.
Nämlich entweder man kann sagen,
okay, wo finden wir dieses Team jetzt wieder?
Innerhalb des Systems,
das Team Topologies aufspannt.
Und dann würde ich sagen,
es ist tatsächlich noch am ehesten
irgendwie ein Enabling Team,
das Unterstützungsleistungen bietet,
temporärer Natur für andere.
Oder man kann den Spieß umdrehen und kann sagen,
alle Modelle sind falsch, aber manche sind nützlich.
Jetzt haben wir einfach eine Grenze des Modells
Team Topologies gefunden.
An der Stelle verliert es vielleicht
so ein bisschen seine Tragfähigkeit.
Also das ist ja tatsächlich,
also das wäre eh immer das,
wozu ich tendieren würde,
weil ich bin ja nicht so der Fan von Dogmatismus.
Das heißt also,
ich finde es ja super,
Team Topologies als Werkzeug einzusetzen,
habe aber nicht den Anspruch,
dass ich meine komplette Welt
nach Team Topologies ausrichte.
Das an das Enabling hatte ich halt auch schon gesagt,
weil im Prinzip ist,
Enabled ist ja die anderen Fokus zu wahren.
Oder es baut halt tatsächlich Sachen,
die in anderen Teams wiederum eingesetzt werden.
Von daher ist halt durchaus,
aber das war so eine der Sachen,
die ich da in der Überlegung ganz spannend fand,
wie man das eigentlich da,
da sich darin wiederfinden würde.
Ja, aber das ist mir so wichtig,
dass ich da tatsächlich nochmal drauf eingehen möchte,
weil mir ging das nämlich auch so,
als ich Team Topologies gelesen habe,
habe ich auch gesagt, also dürfen die das?
Braucht man wirklich nur diese vier Team-Geschmacksrichtungen?
Das geht doch nicht und so.
Ich kann mir da noch andere auch noch ausdenken
und dann bin ich halt auch drauf gekommen,
ist doch total wurscht.
Es geht ja nur darum,
dass man ein Werkzeug hat,
an dem man sich orientieren kann.
Ich sehe Team Topologies,
ich sehe Team Topologies
und diese vier Topologien oder sowas
mittlerweile nicht mehr als diskrete Orte oder sowas,
sondern das ist für mich ein Koordinatensystem.
Und da kann ich sagen,
dieses Team hat,
das ist eher so in der linken unteren Ecke,
was auch immer sich da befindet,
keine Ahnung.
Und insofern,
mei, wenn du möchtest,
nenn dein Team Wolf ein Enabling-Team
und wenn du es nicht möchtest,
ist auch okay,
aber du hast verstanden,
dass es etwas ist,
was ungefähr so aussieht,
wie ein Enabling-Team,
aber vielleicht nicht gemäß der reinen Lehre.
Und jetzt kannst du die Schlüsse daraus ziehen,
die du daraus ziehen möchtest.
Okay.
Ich würde gerne noch einen Punkt ansprechen.
Ich weiß,
dass Felix ein sehr spezielles Verhältnis
zu Spotify,
zum Spotify-Modell hat.
Kannst du das Spotify-Modell
vielleicht doch mal zu Team Topologies mappen?
Das ist jetzt insofern wirklich lustig,
als dass ich tatsächlich noch eine andere Sache mitgebracht habe,
die auf das Spotify-Modell anspricht.
Tatsächlich muss man,
finde ich,
hat ein spezielles Verhältnis zum Spotify-Modell.
Ich finde,
da muss man ein bisschen mehr Kontext geben.
Klar,
das war ich doch erwartet.
Also tatsächlich finde ich es einfach,
findet man ja an der einen oder anderen Stelle
immer wieder die Referenz auf Spotify-Modell.
Und ich pointiere das jetzt mal,
dass das Spotify-Modell der Heilsbringer überhaupt ist.
Und da wird,
das ist halt maximal kurz gedacht,
weil immer vergessen wird,
dass man never ever eine Sache von einer Organisation
auf die andere blind kopieren kann.
Also du kannst halt einfach kein Copy-Paste
von Organisationsentwicklung machen.
Das funktioniert nicht.
Und ich finde es deswegen auch schwierig,
ich finde Copy-Paste an der Stelle schwierig,
auch mit Begrifflichkeiten,
weil das automatisch,
aber das ist jetzt ein sehr persönlicher Gedanke an der Stelle,
das automatisch eine gewisse Schubladenerwartungshaltung
mit sich bringt.
Und ich finde es wichtig,
dass man nicht einfach nur sagt,
oh ja,
Tribes und Guilds und Squads,
sondern dass man sich tatsächlich überlegt,
was wollen wir eigentlich bezwecken
und was ist das Ziel?
Und sich dann das überlegt.
So, das einfach nur so als Kontext dazu.
Also es ist nicht so,
dass ich glaube,
dass das, was Spotify da gemacht hat, Käse ist,
sondern ich glaube,
für Spotify ist das ein sicherlich sehr gutes Modell.
Interessant finde ich tatsächlich die,
wenn man mal so ein bisschen weiterguckt,
was da doch für kontroverse Dinge,
also Berichterstattung und Blogposts
und Erfahrungsposts so gibt,
weil es halt auch nicht,
also es ist ja nur eine Momentanaufnahme gewesen
und auch Spotify hat sich weiterentwickelt
und auch das muss man da immer bedenken.
Und ich meine,
wenn man sich anguckt,
wie eine Organisation wie Spotify wächst,
da hast du ja im Prinzip konstant einfach Änderungen.
Das heißt,
da kannst du gar nicht sagen,
das ist das Modell
und das funktioniert auf x Jahre.
Tatsächlich zu Team Topologies.
Es ist ja so,
dass wenn man sich das Spotify-Modell anschaut
und sowas wie den Tribe oder die Guild hat,
was ja im Prinzip fachliche Zusammenschlüsse sind,
dann habe ich zum Beispiel mir die Frage gestellt,
kann ein Tribe ein Complicated Subsystem Team darstellen?
Also kann man in seiner Organisation,
wenn man,
wenn man,
man hat,
nehmen wir mal einfach mal an,
du hast fünf Stream-Aligned Teams
und über diese fünf Stream-Aligned Teams
könntest du ja im Prinzip etwas wie ein Tribe bauen,
nämlich aus jedem dieser fünf Stream-Aligned Teams
nimmst du die Leute,
die sich mit den Datenbank-Servern beschäftigen,
packst die in ein Tribe
und wäre das dann ein Complicated Subsystem Team?
Das ist was,
wo ich tatsächlich im Augenblick auch gedanklich noch hänge.
Weil man nämlich sonst durchaus sagen kann,
wenn sowas funktioniert und auch tatsächlich gut funktioniert,
dass du halt tatsächlich sagen kannst,
okay, hey, die ganzen Leute,
die sich sonst um die Datenbank-Server kümmern,
die wollen wir ja nicht alle,
wir wollen ja kein Datenbank-Administratoren-Team,
sondern wir wollen halt die Stream-Aligned Teams haben,
wo zum Beispiel überall Leute drin sind,
die von Datenbanken Ahnung haben,
aber die können dann halt eben diesen Interessens,
also diesen fachlichen Interessensverbund
nämlich in Datenbank-Server als Tribe bilden,
was ein Complicated Subsystem Team wäre.
War das okay?
Konnte man dem folgen?
Also ich ja.
Ich konnte ihm folgen,
aber ich konnte ihm nicht zustimmen.
Deswegen habe ich so eine Frage mitgebracht.
Also bei Ihnen.
Okay.
Genau.
Weil sagen wir es mal so.
Ich glaube,
das war nicht das,
was Spotify sich unter einem Tribe vorgestellt hat.
Was hat sich Spotify unter einem Tribe vorgestellt?
Sondern die,
ich sage jetzt mal,
die kleinste Organisationseinheit,
in der Leute aufgehängt sind,
die heißt dann bei Spotify ein Squad.
Das ist dann halt irgendwie einfach nur ein Team.
So zock.
Zum Beispiel ein Complicated Subsystem Team oder sowas.
Genau.
Und Leute mit derselben Funktion
innerhalb verschiedener Squads
sind in einem Tribe drin.
Genau.
Das heißt,
ein Tribe ist sozusagen per Definition
orthogonal zu einem Squad.
Genau.
Stopp.
Ja.
Kann es sein,
dass ihr Tribe falsch interpretiert?
Für mich sind das die Chapter.
Oder ich habe es falsch verstanden?
Du hast recht.
Nein, nein, nein.
Du hast recht.
Ich bringe die auch immer übers Kreuz.
Okay.
Also die Squads sind im Tribe
und dann habe ich die Chapter,
die entsprechend so orthogonal darüber gehen.
Genau.
Dirk hat völlig recht.
Also lass es uns noch mal kurz zusammenfassen,
damit wir auch unsere Hörer
maximal verstehen können.
Ja.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Okay.
Genau.
Sehr gut.
Genau.
Also,
Squads sind,
ne,
sind kleine Einheiten,
sagen wir mal,
nicht mehr als zehn Leute,
einfach nur ein anderes Wort für Team.
Wenn du die zu größeren Organisationseinheiten
zusammengefasst,
zusammenfassen willst,
heißen die bei Spotify Tribes.
Ja.
Richtig.
Ja.
Und du hast ein, was weiß denn ich, Python-Entwickler-Chapter.
Und was dir halt sonst noch so einfällt.
Und insofern kann ich mir schon vorstellen,
dass es in einem Complicated-Subsystem-Team
von Python-Entwicklern wimmelt aus irgendeinem Grund.
Aber das ist halt trotzdem kein Chapter.
Ein Chapter soll ja eine Möglichkeit schaffen,
damit zwischen verschiedenen Squads ein Austausch stattfinden kann.
Dass die sich abstimmen können, dass die Wissen teilen können und so fort.
Dass die zum Beispiel gemeinsam definieren,
wie aber gewisse Sachen in der Datenbank-Server-Architektur stattfinden.
Zum Beispiel, ja.
Genau.
Sie stimmen sich darüber ab,
wie gewisse Sachen in der Datenbank-Server-Architektur stattfinden.
Und sind auch die, die ja per se dann die meiste Ahnung
von den Datenbanken im Unternehmen haben.
Da wäre halt die Frage, ob das nicht dann,
wie automatisch damit dann auch die Ohner von dem Complicated-Subsystem
der Datenbank-Server sind.
Nee, sondern die Idee hinter einem Chapter,
so wie ich das Spotify-Modell verstehe.
Ja, ich meine, wir können es ja verstehen.
Genau.
Die Frage ist aber, ob man, wenn man Streamalign-Teams hat,
ob man eben über das Identifizieren von verschiedenen Fachspezifika,
eben zum Beispiel Datenbank-Server-Menschen,
dann tatsächlich dort eine Gruppierung schaffen kann,
die in einem zusätzlich sozusagen über diesen Interessensverbund
auch die Rolle eines Complicated-Subsystem-Teams erfüllen.
Ja, das könnte sein.
Aber die Idee hinter einem Chapter-Virum ist ja,
das ist eben genau kein separates Team.
Das ist kein Squad.
Sondern die sind weiterhin ganz klar ihrem Squad zugeordnet.
Die sind dem verpflichtet.
Die arbeiten für dieses Squad.
Und haben halt, und reden ab und zu mal mit ihren Kollegen.
So muss man es sehen.
Das ist kein Team.
Ich stimme dir zu, das ist das, was häufig in der Praxis passiert.
Das sind die berühmten Shadow-Org-Charts.
Dass du plötzlich geheime Teams hast,
die sich da irgendwie gebildet haben aus Notwendigkeiten heraus.
Genau.
Und jetzt haben wir aber die Chance,
dass wir eben diesen Shadow-Org-Chart verlassen
und sagen, wir machen das nochmal an einem anderen Beispiel.
Wir nehmen jetzt nicht mal die Datenbank-Server,
sondern wir nehmen das Thema Open Source.
Das heißt also, du hast,
du hast in deinem Unternehmen wiederum fünf Stream-aligned-Teams
oder zehn oder was auch immer und im Prinzip ist es so,
dass aus jedem dieser Teams potenziell Sachen rausfallen,
die entweder für Open Source fähig werden, würdig werden,
die mit der Open Source-Community agieren oder wie auch immer.
Du hast aber nur eine relativ kleine Zahl an Leuten,
die tatsächlich den Erfahrungsschatz haben,
wie man mit einer Open Source-Community interagiert.
Und die hast du aber verteilt auf deine,
deine Stream-aligned-Teams und die Idee ist aber ja,
dass du aus, aus dem Unternehmen heraus in einer Art und Weise
mit der Community interagierst und nicht auf zehn verschiedene Arten und Weisen,
je nachdem wie das und dass du darüber, dass du im Prinzip schaffst,
Stream-aligned-Team übergreifend, weil du in jedem deiner Teams welche hast,
die sich dann aber wiederum als ein Verbund sehen,
um sich daran auszutauschen.
Und wie, die, die Frage ist komplizierte Subsystem-Team ist der falsche Begriff,
aber wie nennt man denn diesen Zusammenschluss?
Um eben nicht diesen Shadow-Org-Chart zu haben und zu sagen,
das ist halt irgendwas, was sich implizit bildet, sondern um es explizit zu machen.
Also wir haben es halt bei uns Cross-Team-Efforts genannt.
Also wir haben halt zum Beispiel einen API-Cross-Team,
wo halt aus jedem Team, was APIs baut, Leute drin sind,
die sich darum kümmern, dass wir halt einen Standard-Weg haben,
wie bei uns APIs auszusehen.
Ja.
Damit alle APIs, die wir haben, dem gleichen Paradigmen folgen.
Wir haben einen CI-CD-Cross-Team.
Wir haben es bei uns halt Cross-Team genannt.
Dass wir einfach Cross-Team-Effort sagen, wo im Prinzip jedes Team die Leute hinschickt,
die in dem Teil wirklich Clou haben, damit sich dort dann alle gut austauschen
und die Ergebnisse wieder in die Teams zurückfließen können,
damit dieser Informationsfluss gewährleistet ist.
Damit eben nicht du pro Team, jeder macht so seine CI-Pipeline,
und dann hast du am Ende irgendwie zehn unterschiedliche Art und Weisen,
wie im Unternehmen CI-CD-Pipelines gebaut werden.
Was ja im Prinzip, das will ja keiner.
Das ist ja dumm.
Habe ich dich jetzt komplett verwirrt, Luca?
Nein.
Aber ich bin mir momentan noch so ein bisschen unschlüssig,
wie da die richtige Antwort aussieht,
weil wir jetzt dann in irgendwelche ganz vertrackten Nuancen reinwandern.
Und ich glaube, wir verwirren dann unsere Hörer zu sehr.
Das ist die Gefahr, die ich sehe.
Ja, aber tatsächlich ist, glaube ich,
und das ist an der Stelle vielleicht die Kurve zu kriegen,
ich glaube, man wird irgendwo immer diese Nuancen dann haben.
Und ich glaube, es ist tatsächlich gut, wenn man,
oder das wäre jetzt so, wenn man tatsächlich mal so ein bisschen schaut,
was man so machen kann.
Ich mag es halt zum Beispiel, über den Tellerrand zu gucken
und hier und dort zu gucken, aber halt nicht blind zu kopieren,
sondern tatsächlich dann einfach zu gucken,
okay, was von dem, was man woanders findet,
kann uns tatsächlich helfen, um es dann mit Bedacht rüberzuholen
und zu adaptieren.
Also eher ein, nicht copy-paste, sondern copy-adaptieren.
Also ich sage immer, kapieren und nicht kopieren.
Ja.
Aber ich habe noch eine gute Idee.
Wir können mit dieser Frage, die wir ja jetzt nicht endgültig gelöst haben,
können wir eine Brücke bauen,
zu Folge 50.
Wir haben jetzt halt die Folge 46.
In der Folge 42 und 43 haben Luca und ich so die theoretischen Grundlagen gelegt.
Jetzt haben wir den Felix mit der Praxis.
Und in der Folge 50 haben wir Matthew Skelton zu Gast,
der einer der beiden Autoren ist.
Also insofern, Luca, Felix, schreibt euch die Frage auf.
Dann können wir die Matthew stellen und an alle Hörer da draußen,
die vielleicht auch Fragen haben zu Team Topologies,
gerne an uns.
Dann können wir die in der Folge 50,
das ist zumindest jetzt der Plan,
das wäre der August,
mit Matthew direkt klären.
Und insofern freuen wir uns,
dass der Matthew zu Gast sein wird.
Und wenn ich jetzt auf die Uhr blicke,
dann sage ich mal so,
wir haben einen Zeitpunkt erreicht,
der zu einem Abgesang führen könnte.
Es sei denn, ihr habt noch zwei Punkte,
also ihr zwei habt noch Punkte, die ihr ansprechen wollt.
Viel zu viele.
Viel zu viele.
Lass uns lieber die Kurve kriegen.
Okay, na gut.
Felix, hast du noch irgendwas?
Nö, aber wir könnten noch.
Also ich habe familyfrei heute Abend.
Ja, also für die geneigten Zuhörer,
wir haben es jetzt hier viertel vor zehn.
Also wir drei haben keinen anderen Termin bekommen,
als hier wirklich spät abends das zu machen.
Ich habe nicht familyfrei, Felix.
Ich muss ja auch ehrlicherweise zugeben,
dass ihr euch nach meinem Terminplan gerichtet habt.
Von daher bin ich auch sehr dankbar,
dass wir überhaupt einen solchen Abendslot machen konnten.
Ja, ja, okay.
Aber es hat sich nicht gelohnt, oder?
Das denke ich schon, ja.
Also insofern, wir haben das zum dritten Mal,
das Thema Team Topologies.
Wir kriegen es dieses Jahr zum vierten Mal.
Also insofern wird das das Team Topologies Jahr
für uns an der Stelle.
Also dann die Bitte, die Aufforderung,
auch an die Zuhörer, Fragen zu stellen zu Team Topologies.
Die können wir gerne mit Messius Gelten dann klären im August.
Ich wollte noch auf einen anderen Punkt hinweisen.
Und zwar auf zwei Punkte eigentlich.
Erstens, nochmals Ergänzung zu Team Topologies.
Wir haben von zwei Hörern des Podcasts die Frage bekommen,
ob wir auch Schulungen haben.
Also ob man da irgendwo eine Schulung buchen kann
zu Team Topologies.
Und wir haben dazu noch keine Idee,
noch kein fertiges Webinar.
Oder wie auch immer.
Aber wenn weiterer Bedarf da ist,
und wenn ihr uns schreibt,
was ihr so in der Schulung haben wolltet,
dann gerne raus damit.
Dass wir einfach auch sehen,
vielleicht gibt es ja am Markt einen gewissen Bedarf,
eine wie auch immer geartete Team Topologies Schulung
oder so ein Webinar oder einen Workshop zu initiieren,
dass man so etwas macht.
Und…
Ich würde dir da…
Ja, bitte.
Bevor du weiterredest,
ich möchte da nochmal ein bisschen konkreter werden.
Hörer, Freunde von Hörern, kommt auf uns zu.
Wir können euch sowas machen.
Wir können euch sowas machen.
Sehr schön.
Das ist nicht nur so hypothetisch,
sondern ich habe total Bock,
da draußen eine Schulung zu machen.
Und wenn mir jemand eine Ausrede liefert,
dann mache ich die auf der Stelle.
Gut.
Also ich würde sie nicht auf der Stelle machen.
Ich würde sie vorbereiten.
Aber das kriegen wir ja hin, Lukas.
Also nicht bis übermorgen.
Aber…
Nee, nee.
Das ist fest auf dem Terminplan.
Ich möchte das ganz gerne machen.
Und insofern,
wenn mir jemand einen Vorwand liefert,
dann bin ich ihm höchst dankbar.
Sehr schön.
Und da kommt der zweite Punkt.
Jetzt kommt ein kleiner Werbeblock.
Aber ich glaube, dass der genehmigt ist.
Wir haben ja auch gesagt,
mit Felix möglichst wenig Werbung.
Aber es kommt ja von sich aus heraus.
Es gibt den DevOps Mastermind Club.
Und die beiden, Luca und Felix,
sind in dem nächsten DevOps Mastermind Club.
Auch da packen wir die URL,
die Webseite dazu rein.
Der Marketing…
Ja, der Marketing.
Der DevOps Mastermind Club.
Startet wieder am 8.
Juli.
8.
Juli startet der.
Und wer Informationen haben will,
wie gesagt, packen wir rein.
Luca wird der Überraschungsgast sein.
Jetzt ist es keine Überraschung mehr,
aber…
Ihr habt es gehört.
Am Ende vom Mastermind Club
gibt es immer so eine Überraschung
oder einen Gast,
der als Überraschung da ist,
zu einem Thema,
was ich mit dem Gast vorbereite.
Und einer der Mitglieder im DevOps Mastermind Club
ist Felix.
Also, wem Felix mit seiner Art
und mit seiner Fachkompetenz sehr gefallen hat,
der kann ihn gerne wiedersehen.
Er muss einfach nur in den Mastermind Club kommen.
Wie gesagt,
Hinweis dazu,
Webseite dazu,
packen wir auch in die Shownotes
beziehungsweise in die Beschreibung.
Gut.
Jetzt haben wir über eine Stunde.
Gibt es noch irgendwas,
was ihr beide sagen wollt?
Ansonsten würde ich sagen,
vielen Dank fürs Zuhören.
Vielen Dank, Luca,
für die Begleitung
und vor allem dir, Felix,
vielen Dank,
dass du uns hier
eine Stunde deiner Zeit geschenkt hast.
Weil auch wenn du Family,
Freie hast,
es gibt ja noch andere Dinge,
mit denen man machen könnte.
Also vielen Dank an dich,
dass du uns hier ein bisschen
bei Gridscale hast reingucken lassen.
Vielen Dank für die Einladung.
Hat mich sehr gefreut.

Klicken Sie auf den unteren Button, um den Inhalt von podcasters.spotify.com zu laden.

Inhalt laden

Our guest today is Paul Swail, an expert on serverless architectures. We discussed the architectural and organisational aspects of serverless:

• what serverless is
• why serverless is the future
• how it provides value to both users and development teams
• which tasks it’s suited or unsuited for
• how to get started with serverless

In this episode of „DevOps auf die Ohren und ins Hirn,“ Luca Ingianni interviews serverless consultant Paul Swail, delving into the world of serverless computing. They discuss the advantages of serverless, such as enhanced focus on business value and reduction in infrastructure management, while also addressing common misconceptions and challenges, including debugging, testing, and integration. The conversation covers practical advice for implementing serverless architectures, including transitioning from traditional setups and scaling serverless applications effectively. The episode offers insights into serverless best practices and emerging trends, making it a valuable resource for developers and teams considering or currently using serverless technology.

Inhalt

• Introduction to Serverless and Guest Paul Swail
• Benefits of Serverless Computing
• Challenges in Serverless Architecture
• Transitioning to Serverless from Traditional Architectures
• Scaling Serverless Applications
• Best Practices in Serverless Deployment
• Debugging and Testing in a Serverless Environment
• Potential Misconceptions and Pitfalls in Serverless
• Emerging Trends in Serverless Technology
• Serverless Resources and Learning Opportunities

Shownotes

Serverless Framework: https://serverless.com

Paul’s Twitter: https://twitter.com/paulswail

Paul’s website and free 5-part email course: https://serverlessfirst.com

Transkript (automatisiert erstellt, wer Fehler findet darf sie behalten)

Welcome to a new episode of DevOps auf die Ohren und ins Hirn, or in English, DevOps from
your ears straight to your brain.
Usually, this is a German-language podcast, but sometimes we make exceptions for international
guests.
Today is one such exception.
My name is Luca Ingianni.
I’m a DevOps consultant, trainer, and coach, trying to get teams to work together better
and create better products for their customers.
And I host this podcast together with my colleague, Dierk Söllner, who unfortunately couldn’t
make it today.
Today, I have the pleasure to introduce my friend, Paul Swail.
Paul, he’s a solo consultant who specializes in serverless.
We’ve had a German-language serverless episode before, episode 26.
I’ll link to it in the show notes.
But while that episode was fairly technical, I wanted to talk to Paul about the higher-level
challenges, the architectural and organizational issues you might face when moving to serverless.
So, hi, Paul.
Thanks a lot for being on our show today.
Hey, Luca.
Thanks a lot for having me.
It’s great to be here.
So, tell us a little bit about yourself, Paul.
Well, as you said, I’m a serverless consultant.
I’m based in Belfast in Ireland.
I’ve been independent for almost 10 years.
For 20 years, I’ve been working in software professionally as an architect and software
engineer, independent for about nine of those years.
And the last three years, I’ve decided to specialize in serverless.
I have been doing some general.
Sort of cloud work, working with Node.js on AWS, sort of container-based.
And then I sort of decided, I’ve sort of seen serverless as sort of the way things are going
generally in software development and decided to specialize in that area about three years
ago now.
So, you said you saw that serverless was the way things were going.
Can you elaborate on that a little bit?
Yeah, I guess it’s sort of related to my whole sort of developer journey or my career.
Everything, I guess as a developer, everything you want to do things faster with a higher
quality, sort of productivity-based.
A lot of the things around serverless is using sort of hosted services and effectively not
doing things that you’ve always thought you had to do, like installing patches on servers,
which is the obvious thing.
And you can just pretty much focus on building apps.
I sort of focus more on the backends nowadays, but I used to do like full-stack front-end
back-end web development and just being able to use services, which just do these things
that you do for every single project.
Just not having to do those is a really big benefit and just being able to hand that off
to a cloud provider.
Yeah.
Who will do that for you, will do part of that for you, just allows you and the rest
of the developers on your team to be able to focus on just the actual business requirements
and just building out what they call the non-undifferentiated heavy lifting.
Yeah, but let’s be honest, serverless still means somebody’s got a server somewhere, right?
So who’s taking care of that server?
Yes, that’s the whole, yeah, it’s a terrible name.
Let’s get that bit out of the way at the start.
It is terrible.
It’s a can of worms when you talk about the name.
Technically, yes, there are absolutely servers there.
It all runs on some sort of Amazon’s or Google’s servers.
So the obvious, like AWS Lambda functions as a service, they run on a server.
The serverless, the word means that you don’t need to think about the server that it’s running on.
It doesn’t mean that it doesn’t exist, but it means that you as the developer or the
architect designing the system don’t need to care.
You can treat a function as your lowest level building block that you can build your applications
and that you don’t really care about, like what operating system or anything like that.
Okay, I see.
Something you just said I found interesting, which is you said,
oh, you don’t really have to worry about servers and patching them and that sort of thing.
And then you sort of qualified that and said, yeah, well, not usually anyway.
What do you mean?
What do you mean by that?
You definitely don’t need to.
It wasn’t qualifying that you don’t need to worry about patching servers.
That is something which has gone away.
If you’re building a fully serverless application.
Now, there are plenty of hybrid type serverless applications where you still would need to do that partly.
But that’s not really what I’m getting at.
And there are still lots of things that won’t go away.
So like your packages.
So if you’re running like Node.js is probably the most popular along with Python,
the most popular Lambda, AWS Lambda languages to use.
Like you still would need to worry about like your NPM packages and keeping them up to date.
So there’s absolutely things which are still things which you wouldn’t consider value add to your business,
to the business problem that you’re working on, which you still need to do.
So it’s not a panacea.
And that solves everything for you.
But one of the key things that I’ve noticed in the teams that I work in, the teams are smaller.
So you need individual developers can take on more ownership of more what you call infrastructure parts of the system.
Whereas in the past, because or in the past with sort of more traditional server based systems,
you really need dedicated people because for those jobs, because they are so,
there is a lot more to them.
So like keeping, getting network configuration all set up and make sure all ports are locked down,
all those sort of concerns, having a front end or a full stack web developer handle all those things can be very risky.
Whereas you don’t, that role goes away if you have a serverless focused development team.
You don’t need that dedicated network sort of systems engineer person on your team.
And you can get away with a smaller sort of set of application based developers and that just bubbles it up to the business level.
The people who are actually the whole point of building the software in the first place is the business value that it’s generating.
And effectively with no engineers don’t like to be seen as a cost.
But the further lower down the stack you are, the more the business would see you as a cost.
Whereas the high F like I always.
The front end developers and the teams that I will work in,
like the designers,
because they get all they’re doing,
they’re getting all the great feedback from from the clients and all that looks great.
That’s exactly the way we look at it.
And that’s like while technically it probably isn’t that difficult what they’ve done,
but it’s the real value has been delivered there to the to the end user,
whereas nobody really cares what servers they don’t care what servers or what Kubernetes stack your,
your,
your,
your apps built on top off as long as it’s up and it’s doing what it’s supposed to be doing and it’s doing that.
Well, that’s that’s where the real value is interesting.
So yeah, you service if I understand this right is really just a way of the entire team being able to focus on customer value.
And and all of the things that are not really a value add gets dealt with by,
you know, the AWS is all the Googles of the world exactly.
Yes.
And yeah, and there are other smaller vendors sort of layering even on top of that.
So AWS have their sort of like the likes of Lambda or DynamoDB sort of like services that you don’t need to do that just sort of you can treat as an API effectively.
And there’s the likes of Netlify and Vercel who are even a layer on top of that,
adding extra developer experience things.
So you like no config or minimal config like automatic CI CD,
just almost out of the box,
lots of sort of layers on top of,
just moving up and up the stack.
But so what I’m what I’m wondering is if we contrasting that with maybe microservices or something which are can we can we say they are more traditional?
I don’t think they’re comparable like you can build you could build a serverless you can build a serverless only microservices architecture.
I don’t think they’re they’re not one or the other.
It’s not either serverless or microservices.
So I could see you could absolutely design it such that every every microservice I hit the term microservice because it implies small or is not necessarily small,
whatever the services are and they could be totally built in serverless only architectures and talk to each other like say via an event bus.
So it would take all the boxes the 12 points for the microservices.
What do you call that now?
The 12 I can’t remember is 12 12 boxes.
You can take you could say this is a microservices architecture and you could totally do that in serverless.
So it’s not one or the other.
But if you’re thinking the sort of more way microservices architectures have been built and either on VMs or on containers and it’s definitely a higher level than that.
So you don’t need to worry about getting a fleet of VMs.
So you don’t need to worry about getting a fleet of VMs.
So you don’t need to worry about getting a fleet of VMs.
Where you run all your containers on top of it.
So you don’t need to worry about all of the deployment issues, really.
I mean, well, you need to deploy your application code, but that’s that’s all there is.
Yeah, you absolutely could.
Like microservices has lots of pros and lots of cons.
So if you think in terms of let’s look at the con, the drawbacks around like the distributed logging, the distributed deployment.
If you could absolutely.
Get all those issues if you build your serverless app in a certain way and some things like the distributed logging is somewhat of an issue.
So you’ve different parts writing to different logs and sort of like there are tools to sort of collate them, but you need to set those up.
But the whole like having a single monolithic deployment of a serverless app, despite like the compute is inherently distributed.
So there’s no getting away from that everything.
Lots of Lambda functions.
But you can deploy them all in a single package effectively in a AWS provides a tool called CloudFormation, which is like an infrastructure is code for effectively deploying a single atomic set of resources in one go.
So it will either deploy it or feel so you can get around like microservices issues of having having to deploy all these things separately by just.
Effectively.
Treating it as a call it distributed monolith, which some people may think that sounds terrible, but the benefit taken the good aspect of the monolithic deployment with the good aspects of the distributed and the scalability of the scalable of the distributed compute that Lambda gives you.
So you get the the simplicity of thinking about a monolithic thing, but you get the infinite scalability.
So you get the simplicity of thinking about a monolithic thing, but you get the infinite scalability of the distributed compute that Lambda gives you.
Exactly, exactly.
Yeah, that’s that’s the way I sort of if you’ve got bigger teams and you could design your serverless app using microservices.
But most of the teams that I’ve worked with, especially on a new on a greenfield project at the start, I always start with like a monolithic deployment.
So everything gets deployed together from the same single repository and deploying everything together.
And you don’t need to reason about.
Just partial deployments and partial rollbacks and that that’s where microservices can get really confusing, especially for a small team and going back to the whole having a team which needs less members, which needs, which can be sort of more application developer focused.
If you start getting into really complex deployment scenarios, then you’re sort of taking away the benefits of going down the serverless route in the first place.
So keeping it simple, just deploying monolithically.
Yeah.
And but still using Lambdas so that Lambda gives you highly scalable compute.
You don’t need to worry about load balancing generally until you’re hitting really large scale.
Okay, wonderful.
You touched on a couple of interesting points there.
Maybe we can spend a couple of minutes looking at that in more detail.
Like, yes, for sure.
Typical the typical ways that I would ask you for, like best practices or something.
But can I ask you for worst practices instead?
Like, what’s how can what are guaranteed ways of messing up your your service application?
Okay, let’s see.
And so I guess one of the big, if you’re coming to Serverless for the first time, your tendency will be to hi.
I get this working on my machine.
And the answer normally is, you don’t.
So you will get part of it, and there are emulators which you could you can use.
But.
for some services, but they’re either subpar or there’s other issues with them.
So I generally say don’t you can run like
the Lambda body of the Lambda code on your own machine.
But anything above that, it’s like you pretty much you need your own cloud
environment, so trying to use get everything running on your own
machine and create AWS emulators, that’s just don’t don’t even try
it because it’s just going to they’re just going to diverge from whatever.
What works on your machine won’t work in the cloud.
That’s you’re just that’s just what’s going to happen.
And so that’s one area and sort of more.
It’s not a it’s not an absolute terrible
thing to do, but it’s sort of it’s becoming a best practice to generally
keep your Lambda function small, preferably single purpose.
So if you’re
say you’re building a REST API
and you’ve got lots of different endpoints and get some posts and for lots
of different resources and you can there are ways you could
effectively just build your whole app inside your whole REST API inside
a single Lambda function, and I’d say that’s a bad idea
for a couple of reasons.
And number one, from a per scalability point of view, if you’ve got one endpoint,
which is a lot, it’s going the way the Lambda will
work and you can lose your concurrency very quickly.
So different functions you can you can throttle them at a certain level.
So if there’s something if there’s something really heavily hit
and you don’t want it to have a knock on effect on the rest of your application,
you can throttle that specific function.
So that’s one area.
But just even from a monitoring point
of view, being able to monitor individual Lambda functions is very powerful.
So you can say have their own logs, you know, OK, this endpoint is getting lots
of errors, that’s quickly fine.
You just know what log file that is because every Lambda function has their own log
file and the likes of just from a code reasoning point of view and
just seeing that specific endpoint, you would be doing it anyway.
If you’re building like, say, ExpressJS Web App, you would probably have your
endpoint built as like a JavaScript function.
And so this just takes that to the next level.
It’s just saying deploying that single code that just that single JavaScript function
to your Lambda and and that has performance benefits because it’s a lot smaller.
The Lambda spins up a lot faster because
it’s just got the code for one function within it, not for the whole application.
OK, so essentially having having a Lambda,
which is like a giant main function with no functions is sounds like a bad idea.
Yeah, I get that. Yeah.
And let’s see what other what other bad practices do we see?
And infrastructure is code or not
using it infrastructure is code.
One of the good things with serverless framework is that
serverless and the serverless framework, which is a specific tool that you can use
for for infrastructure is code and you’re almost forced to define all
your cloud resources within code and you could go into the AWS console and point
and click and create lots of things and deploy things like that.
But you’ll quickly find out that that’s
going to take it’s not it’s not going to be reproducible and it’s going to take
you a long time and it’s going to be very error prone.
So some people still try to do that and they soon get caught out once it comes
to having someone else in their team, if it’s a one person team building a one
person team building a prototype, you could probably get away with it.
But then prototypes always develop into something further.
And then you’re like, OK, we need to define all this in infrastructure as code.
And yeah, there’s a lot of
reverse engineering to try and get what they created down into code.
So I would say start with infrastructure as code from the get go from the very start.
And there are several tools like their
serverless framework, AWS SAM, which do these things for you.
So use them.
OK, so
in a way, it sounds like as long as you use time on a good practice, good software
engineering practice.
You’re going to be OK, right?
And in in certain respects,
yes, there are some evergreen, evergreen
best practices which are always good, no matter what architecture you use
in serverless or whatever.
So keeping things simple, that’s always don’t you aren’t going to need it.
Basic things like that, which like, yeah, always stick to those.
And I guess, yeah, the main paradigm,
paradigm shift, I guess, is is the whole look non local development.
That is something which has been pervasive for developers pretty much
as far as I can remember since since I’ve been a developer anyway.
Like you always had the idea like you
to development, you always get your own development environment working
on your own machine, and that’s generally not the way you would do it.
So that’s I think that’s the biggest difference.
But yeah, other standard
best practices that I mentioned generally.
Yeah, they still hold.
So we’re not we’re not throwing out everything that we’ve learned from the past.
So
does that mean that everything is suited for serverless?
Like, could we just grab any random application and say, yeah,
now we implemented a serverless or are there certain things that are maybe
that just don’t don’t quite work? Yeah.
Well, I would never I’d never.
I’m always like the whole migrating existing apps is a whole issue on its own.
And so that’s there’s lots of nuance,
specifically to each case for for existing apps.
But let’s say you have a new app idea
and you’re saying, should I build this in serverless?
What are the what types of apps or workloads would not be a good fit?
Now, this is a question which is it’s a bit of a moving target.
So if you’d asked me this two years ago, this list would have been longer,
but it’s getting shorter as the cloud providers add features or add new services.
So right now I would say, well,
it’s like a serverless first.
It’s like you if you whatever use cases you have look for a serverless service
which does this and if that doesn’t exist, then use another option.
But what are the reasons why you wouldn’t?
So I would say one of the the current limits is on if you’ve a long running
stateful task like a process which needs to run over a long time
and it uses an existing app which might not have been designed.
For for like a short running
compute like Lambda Lambda has a maximum execution time at the moment of 15 minutes.
So if you have something which needs to run for longer than that, it’s not a good use case.
So an example, I was worked in a client up and they they’ve got an SEO crawler which needs to run.
They’ve got an existing CLI task which crawls website that runs
like it could take four hours for all the different links that it follows.
So that’s yeah, you couldn’t really run that within a Lambda function.
So that’s a use case.
And if you need really low latency from an API, from a rest API,
like you’re talking like single milliseconds and there is a concept of cold
starts, which were a big talking point or a big objection that people using
serverless when it when Lambda functions first came out and they’re much less of an issue.
Cloud providers have mitigated those significantly, but there still is
the very first time you’ve deployed a function, a Lambda function and it gets its first request.
There is a small they call a cold start to load it into memory and to do that.
So that is there’s some like financial transactions.
So it’s like doing computed stock market type apps.
They would be a case where
that wouldn’t be like Lambda based API wouldn’t be a great fit.
And but that list is coming quite like there aren’t many types of new greenfield
applications, which I wouldn’t say don’t start initially with a serverless based
approach.
Yeah, but one other thing, a couple of other types of databases, I would say so
Neo4j graph databases and Elasticsearch are two ones that come
to mind, they don’t have at the moment like what you would call a fully serverless
offering cloud.
So you would need some there are what they would call fully managed hosted
offerings and maybe just explain the difference, what I mean in a minute.
But you still need to pay for you still need to do some upfront capacity
planning for the types of database you would need for those.
And you still
need to
see
the plan for your peak load, not for your average load.
Whereas with serverless you don’t really
need to think about what your peak load is going to be as long as it’s within
the Lambda’s concurrency limit and you’re not paying for peak load.
You’re only paying for exactly what you use.
So there’s sort of an attribute to think
about considering is this service a serverless service?
It’s not easy to say.
Interesting. So, yeah, it was interesting to watch you try and come up with things
that don’t lend themselves to serverless.
It looks like you have to really struggle to to find good examples of.
Yeah, like say about a year ago, I would another item on that list was so if you
had a type of application which was containerized like like a service like
these do I used to get appliances and VMs like a company would put their
their product in a VM and then people would do that with a container as well.
And used to say, OK, no, well, you can’t.
You couldn’t do that in serverless app.
But now there are like Lambda supports container based deployments now as well.
And there’s a there’s a service called AWS Fargate, which is semi sort of
in the hybrid world between containers and serverless where you don’t need to worry
about the servers, but it runs a container on demand.
It spins it up, runs it for the duration
that it needs to run and then it closes down.
And so, yeah, so.
Let’s imagine that I want to get started with serverless.
Just to make it maybe a bit more exciting.
Let’s say I have an existing application and I want to try something new.
How should I do that in a way that doesn’t end in tears?
OK, so, you know, the requirements.
Yeah, I’m going to put aside any
discussions about whether it’s the best use of your time to migrate and exist.
But assume it is not not migrating.
But but, you know, I need some new functionality for this existing app.
So I you know, I think I might as well
instead of creating the microservice or something, I try out this this fancy new
service that’s good because I did this exact thing.
Like I also I have a separate sort of SaaS
product business I’ve been running for about seven, nine years, which was container
based and still going is quite small and but it was built based on containers.
And then three or four years ago I was getting into serverless.
It’s like, OK, a lot of the way I’ve
architected this application would be a better fit for serverless.
And most of my monthly bill would be less as well.
But the actual ongoing maintenance for that I was doing on the servers would go away.
And so what it was a used elastic load balancer, which is a load balancer.
What you can do is I was gradually
and
taking new endpoint, new REST API endpoints that I was adding and rather
than adding them to my existing REST API container based app, I was routing them to
my Lambda functions so you can intercept them
but what they call API gateway,
which is a service, an API service provided by AWS and just route certain requests,
which match a certain path and the new the new API endpoints that I was building.
So rather than routing it to the old
app, it routed it to my new serverless app and then just started building out
the the the new features, the new endpoints within Lambda.
And gradually I never completed the project.
But parts of it and
parts of it is just it’s a way of just extracting.
You’re saying, right, OK, you’re not going to do a big bang crossover.
You can’t because all the risk that that would involve.
You can take piece by piece like endpoint by endpoint.
Where they’re like, like,
within your REST API, say you can just migrate them one at a time over to the new system.
If you’re getting into databases, that gets a bit more complicated or keeping data in sync.
But if it’s purely like the compute part
of your your code, then there are definitely techniques for doing that.
But if you were starting, if you didn’t know anything about serverless at all,
I guess where I usually recommend the people if they if they want to just build
the first deploy the first serverless.
App, say, say REST API.
I keep using that example, but it’s it’s it’s a well-known thing.
Using the serverless framework serverless.com, it has lots of good examples
about quickly defining some endpoints, writing a simple JavaScript,
no JS Lambda function and just getting a response to the cloud
and getting your response back quickly.
OK, so so in essence, what you were describing is just
the classic Strangler pattern.
Exactly. That was exactly the Strangler pattern.
I knew that pattern and I just it wasn’t coming to me.
So I didn’t stumble over it.
Yes, that’s exactly what it is. That’s it.
OK,
wonderful. And that that works well.
And I suppose I suppose that’s really obvious if you think about it.
Just because, you know, serverless, you can write a single
Lambda function, you throw it at the cloud someplace.
And
yeah, and that’s it, isn’t it?
Like there’s nothing else to do, really.
Yeah. And another good use case for getting started.
Sort of like I said, it’s like a low hanging fruit.
If you’re a developer in your organization who are maybe quite skeptical
about serverless and you’re maybe you can see the benefit of it and say, OK,
well, look at all these Cron jobs that we have.
Cron jobs are good, are good, like low hanging fruit where you could say, OK,
Lambda allows you to configure a Cron schedule to run this custom
compute on a on a schedule, either a nightly job to send out email reports
or something like that, whatever it is, having this configure a server just
for that is it has been would be a real pain just having to run those jobs.
Plus you end up doubling up on a server.
You’ve like stuff which is serving front end API and it’s also running back end
jobs in a Cron on the same server and you’re like if it’s a heavyweight
processing job in the background, it could bring down the whole server.
Whereas if you just implement that as a,
as a Lambda function, just run the code in the Lambda function
on a simple configuration schedule and just deploy it.
It just works for you in the cloud.
You don’t need it to
yeah, you don’t need to worry about it
bringing down a server or setting up a server in the first place for it.
Oh, that’s interesting.
That’s that’s such helpful advice, I think, because it’s also such a as you say,
it’s such a nice low hanging fruit because it’s fairly low risk.
Like, yeah, you you’re porting a Cron job or implementing a new Cron job.
Um, as a Lambda function.
And if it doesn’t quite work all that well,
then then maybe you don’t run those emails for a night or something.
Yeah, yeah, yeah.
There’s a good thing of Cron jobs are generally not user facing.
So
are the minimum minimum user in the pack.
So, yeah, they’re a good place to start.
OK, wonderful. So
now I’m all excited about this newfangled serverless thing.
So like how can I
safely grow my my serverless portion of my application?
Like it’s all well and good if it’s like
five Lambdas and I can keep them and I had no problem.
But how do I sustainably build a serverless application?
How do I what do I need to do in order to keep it maintainable,
testable, you know, free from too much technical debt, that sort of thing?
Yeah, yeah.
There’s a few things there and you alluded to it with the number Lambda function.
There’s a criticism which people who haven’t used serverless before often say, OK,
but now I’m just going to end up with a load of Lambda functions to manage.
But you just say you were you from a pure code point of view.
You have the exact same amount of code as
you would have if that was in a monolithic deployment.
They’re just functions, whether it’s a code function on your
file system or a Lambda function in the cloud.
It’s it’s the exact same amount of code from the code point of view.
And there’s a little bit more.
Configuration, I should say, like around you may configure a timeout
for a Lambda function or just the path to the source.
So there’s like a couple of extra lines of YAML, I would say,
but more or less the same amount of code that you would have normally.
And so your considerations then around growing as your as your application grows,
it’s the same as you would for any growing code base.
You still like modularizing it, splitting it, keeping the sensible folder structures.
If it comes to it, consider micro services if your team is starting to
if it’s been worked on by multiple teams possibly and you can sort of come up
with potentially a contract for them to talk to each other at that stage.
You can sort of start splitting your your serverless system into micro services.
And but that’s yeah, that’s going that’s if it’s getting quite big.
And what are they on a monitoring?
So when you’re in production, that’s a there are.
AWS has tools which are OK, I would say for for our operations team for basic stuff.
But if you’ve got a more sort of advanced operational concern,
if you want sort of really fully single, really nice dashboards all looking really
nice, getting all the information in one place, there are third party providers
which sort of aggregate the data that AWS CloudWatch would collect
or it can plug in its own agents into your Lambda code and send
them your data and you get all the nice dashboards and alarms.
And that is something as your application grows and it’s in production that you’ll
need to look into and but AWS CloudWatch, which is their sort of monitoring
logging service out of the box, it does a good enough job, I would say
to get you started anyway before you need to look at third parties.
And I think what else?
Yeah, testability you mentioned.
Yes, so that again.
Last year, in the middle of last year, I ran a survey of a newsletter and
asked several people on LinkedIn to participate.
So I think we’ve got over 150 to 200 responses for people who have been
building serverless apps or have got started and asking the questions really
were around what were the main pain points and the top two.
I mentioned observability and monitoring.
So that was number one.
And number two was testing.
So
testing
I think is an area which again, there’s a slight paradigm shift coming from other
non-serverless based development.
So we start like I mentioned the whole local remote thing and difference.
That is an issue here from the standard.
If you think back, if you know the Martin Fowler or I don’t know who came up
with the original testing pyramid, which has
.
Like a pyramid triangle shape with unit tests at the bottom
and integration tests in the middle and like entry and system tests,
whatever you call them at the top and as it gets up, there are less of them.
So the idea was that the vast majority
of the tests in your system of automated tests would be unit tests.
And then you would have some integration tests and even less end-to-end tests.
That paradigm.
So in my experience and from talking to other serverless experts,
that doesn’t quite hold for
serverless sort of cloud services based applications.
And because the risk now falls to the risk of is less code based,
whereas unit tests are really focused on the code, the actual and procedural codes,
whether it’s Node.js or Java or Python, whatever you’re writing your code in,
that is seen as the biggest risk.
The riskiest area that needs the most testing.
Whereas in serverless apps, it’s not quite that isn’t the case as much.
Now, there you still do write unit tests,
but the integration points between the services become the real
things where the ball can be dropped, where configuration is wrong.
A big thing in AWS land is IAM and IAM.
So it’s
the access control.
Like identity and access management.
Yes, that’s it.
The serverless allows you to define
Lambda functions allow you to find really fine grained permissions on each
function, which is best practice and you do that by default.
But you can very easily, if you did try and run something on your
machine, it would just work because IAM isn’t in play on your own machine.
Whereas you would deploy it into the cloud and it would start,
it would throw an error because it doesn’t have sufficient IAM permissions.
It’s to talk to DynamoDB, let’s say.
And so that’s writing integration tests or
end-to-end tests, even that hit your actual REST API endpoint or your GraphQL
API endpoint to bottom out those issues to make sure
that all the configuration that you’ve written is correct.
So writing integration and end-to-end
tests is much more important when you’re building serverless apps.
Yeah, that’s funny.
It just occurred to me.
If I’m writing a normal Java app,
I don’t need to prove that my function can call another function.
It’s just a given.
And all of a sudden, that’s not quite the case anymore, is it?
Yeah.
When you think of distributed systems,
JavaScript, you can just assume, because they’re very tightly coupled,
they’re like a function, a code, JavaScript, Java function calls another one.
You assume that, but you can’t assume these services in the cloud.
You’re responsible for tying them together.
You’re effectively tying the knot.
Your developers are tying the knot between them and making sure they’re talking
the right language and they have permissions to talk to each other.
That’s all done by infrastructure as code.
So you still need to do right tests to verify that because there are a lot
more integration points between services and cloud resources.
Interesting.
But another thing that worried me,
as somebody who has never tried Serverless before, is how would I be able
to effectively debug something if I throw an input at some function and it maybe
goes through a bunch of different lambdas until it finally reaches its
destination, like a proper integration test.
How can I easily debug where it breaks?
Yeah. So the scenario you talked about there, so multiple lambdas chained together.
So AWS has this service, that sort of orchestration flow, I guess when you’ve
multiple, I guess there’s the choreography and orchestration, which I’m going to,
without getting too deep into the patterns, orchestration is when you have,
you know, like a sequence of actions, integration points between different
services that you want to run in a certain sequence or you may want to
have some extra sort of logic.
But there’s a service called AWS Step Functions, which is,
it’s like a state machine.
You define it in JSON or YAML and different states.
For each state you would say have a task,
which would be implemented as a lambda function.
And it has a nice visual in the console, in the browser.
It has a nice visual
green or red.
So if something fails, it will just pile it in red.
You just click through to the red and it will have the logs for that right beside it.
So that
means for like a multi, for an orchestrated workflow is
very good at helping you debug what went wrong.
And for, I mentioned also what we call
a choreography style sort of integrations where each sort of piece,
say you have like an order management service was the
canonical example where you have a website like Amazon.com where you place an order
and it just publishes an event.
And then you have lots of other
microservices, which then consume that they sort of pull messages,
pull or read the message off the bus and do their own thing like delivery,
shipping or pricing that they just by their whole distributed nature are
generally harder to debug. So if something goes wrong, you need to check.
You’re sort of at the point where you check all those points.
Did the message get published in the first place?
Okay, no. Okay.
Then narrowing it down
from there, whereas, okay, is it a downstream service which just failed?
Then you end up looking the logs for that specific service.
So, yeah, if you’ve got choreographed sort of workflows, they are generally
the hardest to debug once they’re once they’re live.
Okay. So no, no.
Just like stepping through
a piece of your code or something that’s just not no, no, no.
There is.
AWS CloudWatch logs.
So it’s where Lambda and other AWS services write their logs to.
It does have a say you have a transaction
ID, which is the same value through all this.
It passes through all like the order service, your shipping service.
You can filter on, say it’s a UID.
You can do a search within it.
It’s quite slow and limited, but there are other if you were using a sort of richer
than logging like logging aggregation service,
that would probably be an easier way of doing it.
So but if you have what they call
yeah, just that unique transaction ID or correlation ID, which correlates all
the different messages for that single transaction across the different services,
that really helps. Okay.
So I think now I feel quite confident that I can build my first
serverless like application.
Is there something we’ve missed?
You know, given that this this episode is called Practical Serverless.
I think you’ve been pretty thorough.
And yeah, I guess I’ve probably been more back end focused.
So I’m talking a lot about Lambda functions.
That’s more about my recent experience in the last couple of years.
But there are, I guess, going back to the whole mindset
of serverless and encouraging, bringing this thing of bringing development
up the stack and closer to the end user.
So if you’re thinking about empowering,
I sort of like to think eventually not front end developers,
but people who build the front end can build more.
There’s more services coming for for them so that they even some of the lower
even Lambda within some of the features of it will be too low level for
some like the likes of Netlify and Vercel or they have they abstract
a lot about you can run server side code and serverless function,
which under the hood uses Lambda.
But I have like a client who is semi technical, who’s like starting.
I wouldn’t recommend them necessarily jumping straight into writing raw Lambda,
whereas the likes of Vercel or Netlify is a really nice on ramp for someone who is
like building a web app and they need a little bit of server side,
server side functionality to run some code on the server, say when the form is submitted.
And that’s a really nice place to start.
Interesting.
I feel like this is an excellent place to to wrap up, but I feel like I really
should mention that the great workshops that’s that Paul does.
I’ve been I took one of his serverless testing workshops.
When was it last?
Last week? Yeah, it was.
Yeah, it was November. It was November.
We did that. Yeah, yeah, yeah, exactly.
I think it was it was really, really great.
So
just from from personal experience,
if you need so less stuff, go talk to Paul just because not only because he
knows what he’s doing, but also because he’s really great at teaching it.
If people wanted to talk to you, Paul, where could they find you?
Yeah, sure.
And so my website is serverlessfirst.com.
And so if you go there on the home page, I have a link to
like a five part email course for helping people sort of if you’re interested in
getting up to up to speed on serverless and or moving your team over to it
potentially or finding the low hanging fruit that we that we mentioned in the episode.
And I cover those things in that email course.
So that’s serverlessfirst.com.
And you can also get me on Twitter at Paul Swail, S-W-A-I-L.
And yeah, and my other like I do some consulting and my workshops that Luca mentioned.
They’re all on that website as well.
When’s the next workshop going to be, by the way?
And at the minute, I think we’re talking
late spring, possibly possibly May this year.
So, yeah, I’m planning it next week.
So hopefully
and I’m hoping to make it’s going to be a workshop.
But I think I’m also going to have a course option.
So and so you’ll be able to take it on your totally on your own time.
It’s self-paced anyway with with meetups, but there will also be a fully self-paced
option at a lower price.
If anybody’s interested.
Oh, nice. OK.
Paul, thank you so far, so much for being here.
This was a really interesting episode.
Yep, it was great. Thanks very much, Luca, for having me.
Great fun chatting.
Thanks a lot. See you next time, Paul.
Cheers, man. Bye bye.
Bye bye.

Klicken Sie auf den unteren Button, um den Inhalt von podcasters.spotify.com zu laden.

Inhalt laden

Wir haben Rolf Katzenberger zu Gast und sprechen über das Thema Teams. Als Einstieg dazu nutzen wir das Tuckman Phasenmodell der Teamentwicklung und gehen auf die einzelnen Phasen ein. Wir klären, ob es überhaupt Phasen sind, die quasi zwangsläufig aufeinander folgen (müssen) oder ob es nicht vielmehr bestimmte Zustände sind („Stages“ versus „States“). Wir diskutieren alternative Ansätze wie Host Leadership oder New Authority und wir klären, was ein Maulwurfshügel mit Coaching zu tun hat.

In dieser Folge des Podcasts „DevOps Auf die Ohren und ins Hirn“ unterhalten sich Luca Ingianni und Dierk Söllner mit dem Gast Rolf Katzenberger über das Thema Teamentwicklung, insbesondere im Kontext von DevOps. Sie hinterfragen das etablierte Tuckman-Modell der Team-Entwicklung und diskutieren dessen Relevanz und Einschränkungen. Der Gast, Rolf Katzenberger, bringt alternative Ansätze und Modelle wie Host Leadership und das Carnarvon-Modell zur Sprache, die einen moderneren und flexibleren Blick auf Teamentwicklung und Führungsarbeit werfen, weg von starr definierten Phasen hin zu dynamischen Zuständen und kontextbezogenem Verständnis von Teamarbeit.

Inhalt

• Einleitung und Vorstellung des Gasts
• Diskussion über das Tuckman-Modell der Team-Entwicklung
• Kritik und Einschränkungen des Tuckman-Modells
• Vorstellung alternativer Ansätze zur Teamentwicklung
• Host Leadership und seine Anwendung im Teamkontext
• Das Carnarvon-Modell und seine Relevanz für Teams
• Rolle der Führung in der modernen Teamarbeit
• Lösungsorientierte Ansätze zur Konfliktbewältigung und Teamentwicklung
• Abschließende Gedanken und Empfehlungen für die Hörer

Shownotes:

Webseite „Richtig ist, was funktioniert.“

Webseite „Focus on People, Spaces, Time. Workshop Facilitation Reduced to the Max.“

Transkript (automatisiert erstellt, wer Fehler findet darf sie behalten)

Def Ops. Auf die Ohren und ins Hirn. Ein Podcast rund um Def Ops. Von Luca Injani und Dirk Söhner.
Hallo und herzlich willkommen zu einer neuen Folge des Podcasts Def Ops. Auf die Ohren und ins Hirn.
Gestaltet und produziert von Luca Injani und Dirk Söhner.
Hallo, grüß euch.
Wir sind Def Ops Trainer und Coaches mit langjähriger Erfahrung und laden uns gerne Experten aus der Praxis ein.
Ihr habt ja die letzten beiden Folgen gesehen, die letzten drei Folgen waren es ja sogar, wo wir zu zweit gesprochen haben.
Heute haben wir wieder einen Gast. Das Thema heute lautet Teamwork makes the dream work.
Zu Gast haben wir Rolf Katzenberger, der jetzt gerade schon nett lächelt und sich über das Thema aufreut.
Rolf Katzenberger kenne ich schon einige.
Ich habe ihn kennengelernt als Trainer für Training from the back of the room.
Die, die mich als Trainer kennen, werden hoffentlich bestätigen können, dass ich das, was ich bei Rolf mal gelernt habe, auch umsetzen kann oder umsetze.
Wie macht man gute Trainings?
Und insofern, Rolf Katzenberger macht noch ein bisschen mehr.
Und ich würde mal so sagen, Rolf, ich übergebe dann mal gleich an dich zu deiner Vorstellung und zur Vorstellung des Themas heute.
Ja, also hi Dirk, hi Luca. Ich freue mich über die Einladung. Dankeschön.
Ja, du hast es ja schon erwähnt. Wir haben uns beim Training kennengelernt.
Training from the back of the room, was so eine Train-the-Trainer-Angelegenheit ist.
Im Moment bin ich relativ stark im Bereich Facilitation eher unterwegs, also weniger Training.
Und arbeite auch noch als Coach und konzentriere mich da so im Wesentlichen auf so Hilfstechniken wie Accelerated Learning, Host Leadership, Hosting Brains
und versuche eben…
Dann mich auch in meiner Arbeit mehr auf die Team-Ebene zu konzentrieren.
Das ist auch so der Schwenk, was uns hier wahrscheinlich heute zusammenbringt.
Du hattest ja mal etwas gepostet über das Thema, das Tuckman-Modell, das Phasen-Modell für die Team-Entwicklung,
worüber wir wieder in Kontakt gekommen sind.
Und das fand ich ziemlich spannend, weil ich mich da auch schon ein bisschen reingefuchst habe.
Und weil das eine der vielen Studien ist, die sehr viel zitiert wird, aber relativ wenig gelesen.
Und dann dachte ich mir, das ist doch ein gutes Thema, um sich darüber zu unterhalten.
Super, richtig.
Ja, weil für die, die die letzten beiden Folgen nicht gehört haben, noch mal sowas stand in dem Post drin.
Ein Teilnehmer hat sich über das alte Modell von Conway’s Law mokiert.
Und dann habe ich gesagt, ich habe noch ein anderes altes Modell.
Und was trotzdem noch interessant ist, also zumindest aus meiner Sicht, aber vielleicht kriegen wir von dir ja heute noch ein paar mehr Einblicke in das Thema.
Bevor wir in das Thema…
Thema einsteigen mit Team und Teamwork.
Wir fragen ja immer unsere Gäste nach der Definition von DevOps.
Wie würde denn deine Definition von DevOps aussehen?
Ja, also dass die Frage kommt, wusste ich ja, weil ich habe mir ein paar von euren Podcasts schon angehört.
Ich würde es eher über die Haltung definieren, obwohl ich natürlich auch aus der Softwareentwicklungsecke komme.
Aber ich würde sagen, DevOps ist, wenn mir bei der Arbeit die nachhaltig guten Ergebnisse wichtiger sind als ein eigenes Königreich.
Das ist meine Definition von DevOps.
Oh, cool.
Oh, die müssen wir rausnehmen.
Also ich habe ja schon gesagt, wir müssen mal, irgendwann muss man sich noch nicht mal dransetzen und jede oder alle Definitionen mal rausschneiden.
Und da so eine Folge draus machen, DevOps-Definitionen.
Und ja, klingt gut.
Super.
DevOps, warum jetzt Team und DevOps?
Auch da, die die fleißigen Hörer, die regelmäßigen Hörer werden das wissen, dass DevOps aus meiner Sicht, aus unserer Sicht, Luca,
ziemlich stark das Thema Teams betrifft.
Und wir haben ja auch gerade in den letzten beiden Folgen über das Thema Teams gesprochen.
Da ging das mehr über das Thema von außen.
Also was, wie wirken Teams quasi nach außen?
Wir haben über die Teams-Topologies gesprochen, die Architektur und Teams-Zusammenhängen.
Und ich denke mal, wenn wir jetzt über Tuckman sprechen und deine Insights da reinnehmen,
dass das mehr so in das Innen geht von den Teams.
Das heißt, letzten Endes als erster Einstieg.
Wie sehen denn Teams von innen aus?
Was sagt dieses Tuckman-Modell dazu?
Ja, wie das Team von innen aussieht, dazu sagt das Tuckman-Modell selber relativ wenig aus.
Also es wird erstaunlich viel über die Beobachterperspektive geschrieben.
Also wie sieht das von außen aus?
Für mich ist dann an der Stelle eher die Frage, wenn ich ein Teammitglied bin, woran merke ich denn persönlich, dass ich in einem bin?
Also völlig unabhängig von Tuckman.
Also für mich.
Für mich ist es an vielen Faktoren erkennbar.
Also auf der Skills-Ebene zum Beispiel würde ich sagen, erkenne ich ein Team von innen, wenn ich sehe, dass sich die anderen wünschen oder auch darauf vertrauen, dass ich T-Shaped bin von den Skills her.
Das heißt also, dass ich nicht nur sehr tiefe Kenntnisse in meinem einen Bereich habe, also den senkrechten Balken von dem T-Abdeck,
sondern wenn ich auch noch in die Breite gehen kann und auch in den Grauzonen bewusst arbeiten kann.
Also wenn das Team darauf achtet, dass die Übergangszonen genutzt werden und man jetzt nicht jeweils als der Fachidiot endet, der halt nur in seinem kleinen Königreich brauchbar ist.
Also ein Team hat keine Rockstars oder andere Single Points of Failure in dem Sinne.
Ganz handfest merkt man es auch an der praktischen Arbeit.
Also wenn ich mir ein Board anschaue von einem Team im Vergleich zu einer Arbeitsgruppe, dann sehe ich halt, dass unter den Tasks im Schnitt vielleicht 1,5 Namen von Bearbeiterinnen.
Also wenn ich irgendwo sehe, dass unter einem Tasten nur ein Name drunter steht, dann weiß ich, ich bin in einer Arbeitsgruppe von ihnen.
Das spüre ich auch an anderen Kriterien, aber das ist so von der täglichen Arbeit her was.
Ich spüre auch, wenn ich von drinnen aus gucke, spüre ich eine Teamidentität.
Das ist von außen vielleicht relativ schwer zu sehen.
Das heißt, ein Team kann auch auf den Punkt bringen, wovon es mehr will.
Nicht nur, wir wollen weniger Probleme, bitteschön, Punkt, Punkt, Punkt.
Sondern es kann auch auf den Punkt bringen, wonach es strebt, was es interessiert, was es ausmacht.
Merkt man relativ leicht zum Beispiel in den Retrospektiven, wenn also nur darüber gesprochen wird, was alles schiefläuft und warum müssen wir uns überhaupt zu einer Retro treffen.
Ist doch schon alles besprochen und die gleichen Probleme wiederzukommen, bringt doch keinen Sinn.
Dann weiß ich auch, dass ich in einer Arbeitsgruppe bin.
Das heißt, ein bisschen wie beim Fußball.
Also ein Team spricht darüber, wie kommen wir auf dem schnellsten Weg der Champions League näher.
Und eine Arbeitsgruppe spricht eher darüber, wie kämpfen wir gegen die Nachfolger.
Also ein Problem nach dem anderen durchsprüht.
Das ist also gefühlsmäßig.
Hängt wahrscheinlich auch darauf ab, in welcher Liga man dann spielt, ne?
Nö, eigentlich in jeder Liga.
Also ich meine, die begeisterten Fights siehst du ja im DFB-Pokal.
Also wenn irgendein absoluter Underdog dann entdeckt, wofür es sich zu kämpfen, dann ist das ja eigentlich ganz schön.
Last but not least ist noch der Kontext wichtig.
Also ich denke, der Respekt vor den anderen Teams.
Das merkt man auch.
Also wenn nicht über die da geredet wird und man dann so anonym.
Auf andere verweist, Abteilungen oder Arbeitsgruppen oder so etwas.
Sondern wenn man den Respekt für andere Teams auch aufbringt und weiß, dass man ja im Kontext arbeitet.
So wie bei DevOps auch.
Also ich schmeiße da nicht einfach irgendwas über eine Mauer, sondern mir ist bewusst, was das bedeutet.
Also ich reiche es sozusagen wertschätzend weiter vielleicht, aber ich schmeiße es nicht über die Mauer und sage,
ist mir doch egal, was da draus wird.
Also von innen her sieht man viel mehr.
Ja, okay.
Wir haben ja immer von diesem Takt-Mail-Modell gesprochen.
Diese vier Phasen kennt man.
Ich glaube, dass du nicht wirklich von Phasen sprichst.
Das ist schon mal so als erste Überleitung.
Aber kannst du mal kurz diese vier Phasen, auch wenn es vielleicht keine sind, mal kurz darstellen?
Ja, also vielleicht ein bisschen eingepackt in den Kontext noch.
Das Modell ist ja zwei Jahre älter als ich.
Also ich überlasse mal den Googlern rauszufinden, wie alt es wohl sein könnte.
Ist sehr alt.
Er hat das aus einer Literaturanalyse herauskristallisiert.
Und zwar mit der ausdrücklichen.
Maßgabe, ich schreibe ein Modell auf, was eher eine Konzeptualisierung darstellt.
Also überprüfen mögen das dann bitte andere später in Studien.
Er hat also explizit nicht behauptet, dass das jetzt auf irgendwelchen empirischen Datenbüchern,
die man dann untersuchen könnte.
Das sind die vier Phasen Forming, Storming, Norming, Performing.
Die sind aus Knackigkeitsgründen wahrscheinlich so benannt, bedeuten aber…
Ich hasse das.
Ich kann das Takt-Mail-Modell schon nicht leiden, weil das so rein dich oder ich hau dich ist.
Ganz unabhängig von der Wertschätzung.
Die Wertigkeit seines Inhalts oder so was.
Ja, das ist die Ursache seines Erfolges.
Also der Punkt ist ja, ich habe ja gerade erwähnt, das ist gar nicht irgendwie verifiziert und auch nicht validiert.
Das heißt also, es hat sich sehr stark verbreitet, weil jeder denkt, es sei wissenschaftlich fundiert und überprüft ist es aber gar nicht.
Wobei Taktman eigentlich, wenn man das genau liest, wie es ja bei vielen Studien ist, gar nicht so drauf ist.
Also Forming ist für ihn die erste Phase, so die Orientierungsphase und Ausflutungsphase.
Also ich lote aus.
Taktman beschreibt es ja immer unter dem Beziehungsmodell.
Beziehungsaspekt, also was bedeutet es für die Gruppe und unter dem Taskaspekt, also für die Arbeit der Gruppe.
Und Orientierungsphase und Ausflutungsphase des Forming ist für ihn, was ist akzeptiertes Verhalten in der Gruppe?
Und auf den Task bezogen, was will eigentlich das Unternehmen von mir?
Was soll ich da leisten oder tun oder liefern?
Das ist also der Inhalt der Forming-Phase.
Storming folgt dann darauf und ist für Taktman quasi der Widerstand.
Also der Widerstand des Individuums gegen die Unterordnung unter die Gruppe will ich nicht.
Möchte ich nicht.
Und auch unter sozusagen eine neue Arbeitsweise.
Also warum soll ich, wenn ich doch weiß, wie ich den Task löse, da brauche ich doch keine Gruppe dazu, die mir das erklärt.
Das ist also der Inhalt der Storming-Phase.
Da folgt für ihn die Norming-Phase.
Das ist das Überraschendste, wenn man Norming im Vergleich zu dem liest, was er tatsächlich schreibt.
Also da geht es relativ wenig eigentlich um Normen, sondern um den Begriff der Offenheit.
Also in der Norming-Phase ist die Gruppe so erhaltenswert für dich geworden,
dass du angeblich dann die Eigenheiten der anderen Gruppenmitglieder tolerierst und auch offen bist demgegenüber auf der Beziehungsebene.
Und auf der Sachebene sagst du dann, ja, also ich bin eigentlich offen für fachliche Diskussionen über Vorgehensweisen und über Inhalte,
weil du eben schon Wert darauf legst, dass diese Gruppe erhalten bleibt.
Also das ist das, was er unter Norming versteht.
Und es hat eigentlich jetzt mit Normen, wie man das so intuitiv verstehen würde, gar nicht so direkt viel zu tun.
Also die letzte Phase ist dann natürlich die hellstrahlendste Phase, das Performing.
Und da schreibt er auch nicht viel mehr dazu, außer dass dann das konstruktive Handeln eben gelebt wird,
dass man voll in diesen neu definierten zweckdienlichen Rollen aufgeht.
Und auf der Beziehungsebene eben und auf der Task-Ebene, dass sich dann eben erste Ergebnisse, Lösungen, Erkenntnisse zeigen.
Und wie gesagt, also muss man dreimal unterstreichen, er selber hat auch nie behauptet,
50 Studien, aus denen er seine Erkenntnisse, das so extrahiert hat, rausgezogen hat.
Da ist auch sehr wenig Empirie drin vorhanden, das sagt er auch alles selber.
Sondern er sagt ausdrücklich, das sind Konzepte, die habe ich mir ausgedacht, aus den Fingern gesogen,
damit bitte in nachfolgenden Studien vielleicht mal jemand das überprüft.
Und, haben Sie?
Nee.
Kaum, kaum. Also nein, ist ein bisschen zu stark ausgedrückt.
So sechs Jahre, nachdem er das publiziert hatte, gab es eine Studie.
Die hat es…
Tuckman selber sich angeschaut und gesagt, hm, also die sagt jetzt über das Modell eigentlich relativ wenig aus.
Und dann war lange, lange, lange Zeit Ruhe.
Also bis zum Jahr 2005, dann gab es eine Doktorarbeit darüber.
Die habe ich leider nicht in die Finger bekommen, die hätte ich gerne noch gelesen.
Ist aber kaum zu bekommen.
Und es gab eine Militärstudie im Jahr darauf, 2006, die 2007 publiziert ist, vom US-Militär.
Und da nehmen die meisten Leute auch Bezug darauf, wenn sie sagen, dass das Tuckman-Modell nicht stimmt,
weil angeblich diese Studie das gezeigt hat.
Die hat allerdings ein paar gravierende Mängel.
Also sie beschäftigt sich mit sehr, sehr speziellen Gruppen.
Also Einkäufer des US-Militärs, die an einer Schulung, an einer Militärakademie teilnehmen,
wo sie einen Kurs absolvieren, wo Teamwork eingeübt werden soll.
Und dauert im Schnitt ungefähr vier Stunden.
Und das Ergebnis ist dann das Ergebnis eines simulierten Projektes,
das von einem der Instruktoren dann bewertet wird.
Und also ist schon in der Aussagekraft deutlichst eingegrenzt nach allen Richtungen.
Und ja, die Zeitraum von vier Stunden ist, glaube ich, jetzt nicht wirklich so hilfreich,
wenn man da weitreichende Folgerungen ableiten will.
Und es gibt auch deutliche methodische Mängel.
Also es beruht auf Selbsteinschätzung dann.
Also die Leute sollen dann auf einer Zeitachse im Fünf-Minuten-Raster ankreuzen,
wann sich irgendwo etwas geeignet hat, was auf eine der Tuckman-Phasen hindeuten könnte.
Und das ist, also ich habe keine Freude gehabt, das durchzulesen und habe es aber trotzdem mal gemacht.
Ja, also ich glaube, das Tuckman-Modell lebt davon.
Dass es sehr griffig ist, sehr knackig ist und dass eben jeder denkt, es sei überprüft und gültig,
was es aber gar nicht ist. Noch nicht.
Okay. Ja, noch nicht.
Ich meine, es sind ja schon ein paar Jährchen her, dass man es hätte überprüfen können.
Das heißt eigentlich, kurz gefasst, die Welt würde sich genauso weiterentwickeln und bewegen,
wenn wir das Tuckman-Modell nicht hätten.
Naja, es macht schon einen Unterschied aus, ob es jeder glaubt und ob man deswegen glaubt,
dass man die Teams durch diese Phasen durchjagen muss quasi.
Also ich glaube…
Nicht, dass es völlig wertlos ist, aber man kann ein bisschen lockerer damit umgehen.
Ja, da gibt es doch diesen Ausspruch.
Alle Modelle sind falsch, aber manche sind nützlich.
Und vielleicht muss man es aus dieser Warte sehen.
Ja, das gilt für viele Modelle.
Es ist halt nur der Punkt, wie man mit solchen Metaphern umgeht.
Also wenn man sagt, generell, obwohl gerne die wissenschaftliche Seriosität,
weil es halt so schön knackig klingt,
dann landet man irgendwann so beim Modell Trump.
Hauptsache, es klingt bissig knackig und ich komme damit durch.
Ob das jetzt irgendwas mit irgendeiner Realität zu tun hat, schert mich nicht.
Ist ja auch nützlich für meine Zwecke.
Da möchte ich ehrlich gesagt nicht enden.
Nee.
Okay.
Du hast ja gesagt, oder damals, als wir uns darüber unterhalten haben,
dass es eigentlich nicht wirklich Phasen sind.
So habe ich das zumindest verstanden.
Also eigentlich sind es…
Ja, Möglichkeiten, in denen sich ein Team befinden kann.
Ich glaube selber, ich habe nur mal gelesen, die können auch sehr, sehr kurz sein.
Also wenn man jetzt wirklich von Phasen spricht oder um diese Phasen hätte,
ist gar nichts über die Länge ausgesagt.
Was kannst du dazu noch sagen?
Na gut, ich würde es nicht als Stages interpretieren, also nicht als Stufen.
Ich würde es eher als States interpretieren.
Und ich denke, das ist auch nicht allzu weit hergeholt,
weil jeder hat aus der eigenen Berufserfahrung schon erlebt,
dass man sich in diesen Zuständen…
ständig hin und her bewegen kann.
Also es gibt solche Dinge und deswegen ist es auch nützlich,
wenn man diese zwingende zeitliche Aufeinanderfolge einfach ad acta legt
und sich fragt, okay, wenn ich jetzt so etwas erlebe wie Forming
oder so etwas erlebe wie Storming, was gibt es dann für Möglichkeiten,
wie ich an der Stelle passend reagieren kann?
Also es ist…
Der Aspekt, den würde ich auf jeden Fall rausziehen, das ist eigentlich völlig okay,
wenn ich das mehr als Zustände oder als Herausforderung
betrachte und zum anderen hat TACMEN natürlich schon eine richtige Fleißarbeit hingelegt.
Also hat 50 Studien aus verschiedensten Bereichen sich angeschaut.
Größtenteils leider aus Psychotherapie und Verhaltenstherapie, aber der Grundgedanke,
dass ich mir angucke, wie es in anderen Teams abläuft und da auch
mir wissenschaftliche Studien dazu durchlese und Anregungen mir erhole,
den finde ich eigentlich auch ganz praktikabel.
Okay, also wenn ich dich richtig verstehe, dass TACMEN
als Phasenmodell mit seiner Abfolge der Phasen ist eigentlich nicht wirklich hilfreich,
aber diese Abgrenzung von verschiedenen Zuständen, mit der bist du schon einigermaßen zufrieden.
Habe ich dich da so richtig verstanden?
Also nicht die Abfolge der Zustände, aber du befindest dich immer wieder in einem Zustand,
wo du dich orientieren musst, sagen wir es mal so, wie TACMEN das ja auch formuliert hat.
Und deswegen ist es ja nicht unbedingt hilfreich, wenn ich mir jetzt das als Phasenmodell vorstelle
und mir überlege, wie komme ich da schnell wieder raus, sondern einfach,
wenn ich mich in die Situation reinversetze, die auch viele andere schon erlebt haben,
und mich dann frage, okay, was gibt die Literatur dazu her, was kann ich an der Stelle tun?
Und das finde ich eigentlich ziemlich clever, weil das sind jetzt nicht per se weit hergeholte Begriffe,
nur diese Phasenabfolge finde ich halt ein bisschen suspekt.
Okay, das heißt, ja, wie gesagt, nicht Stages, sondern States, und dann kann ich mir überlegen,
in einer der vier Phasen bin ich dann wahrscheinlich.
Oder gibt es noch mehr Phasen, also noch mehr Zustände, die wir nicht mit dieser In-Formel haben?
Die gibt es definitiv. Also eine Sache, die man jetzt in den letzten Jahren relativ schnell sich erarbeiten musste,
ist, dass ein Team ohne Kontext einfach nicht denkbar ist.
Also du kannst zwar solche Herausforderungen standardisieren und versuchen zu abstreichen und Konzepte aufzustellen,
aber du musst mit dem Team arbeiten.
Du musst mit einem Team wirklich arbeiten in seinem eigenen Kontext.
Es gibt kein kontextfreies Team, von daher gibt es auch eine Vielzahl, Myriaden von möglichen Zuständen,
und es geht ja nicht darum, dass du jetzt dem Team beibringst, in welchem Zustand es ist,
dass es es doch bitte schnell erkennen möge, sondern umgekehrt, du musst dem Team zuhören,
in welchem Zustand es selber denkt, dass es sich befindet, und dann versuchen, mit dem Team danach zu arbeiten,
wenn es ein unbefriedigender Zustand ist, wenn man wieder rauskommt, oder wenn es ein befriedigender ist, wenn man drin bleibt.
Okay.
Jetzt spricht man ja häufig von Teambildung, Teamentwicklung,
und wir hatten ja vorhin auch darüber gesprochen in meiner Einleitung,
dass ich so ein bisschen gesehen habe, in den letzten beiden Folgen war eher von außen Tugman, vielleicht eher von innen.
Kann man denn Tugmans Ideen auch nutzen für Teambildung, für Teamentwicklung?
Ja, also, Building ist was anderes als, wenn ich jetzt mal,
Establishing nennen würde. Also ein Team einrichten ist schnell gemacht, aber Building im Sinne von,
dass hier etwas aufgebaut wird, was dann seine eigene Identität hat, da bin ich sehr skeptisch, ob man das von außen kann.
Also ein bisschen, das ist so ein bisschen wie eine Frankenstein-Frage.
Also, kann ich was zusammengebasteltes zum Leben erwecken, wenn ich nur ordentlich Strom drauf gebe?
Und ich würde sagen, nee, das ist jetzt nicht wirklich eine zielführende Strategie.
Also, gerade wenn man Forming sich nochmal anschaut, Tugman sagt ja,
das ist ein Orientieren und Ausloten und das passiert von innen.
Also, das passiert nicht von außen durch Formen von irgendetwas.
Man gewinnt also ein bisschen mehr, wenn man sich alternative Modelle anguckt,
wenn man wirklich von außen was tun will, wenn man sich so Sachen anschaut wie Host Leadership,
also mehr Gast geben als führen oder wenn man aus dem Carnabian-Modell ein bisschen was herauszieht.
Also, zum Beispiel auch die klare Unterscheidung, was kann ich eigentlich nur beobachten?
Also, zum Beispiel die Teamidentität versus was kann ich tatsächlich managen? Also, Constraints, Rahmenbedingungen, Dienstregeln,
Kadenzen, Rhythmen, solche Sachen. Die habe ich von außen im Griff, da kann ich etwas tun,
aber das würde ich nicht als Forming betrachten.
Ich würde auch, ehrlich gesagt, den zeitlichen Aspekt ein bisschen beachten.
Also, es ist wichtig, proaktiv zu sein und nicht Teambuilding auf die Agenda zu setzen,
nur weil man jetzt gerade am grünen Tisch beschlossen hat, dass es neue Teams geben muss.
Also, das ist ja die Grundkrankheit von klassischem Change Management.
Man geht erst dann zu den Leuten hin und bittet sie um ihr Engagement und ihre Begeisterung
und das Aufgreifen von Ideen, wenn man selber schon Beschlüsse gefasst hat.
Und dann braucht man sich auch nicht wundern, wenn jemand sagt,
ja, hey, du hast mich die ganze Zeit nicht gefragt und jetzt soll ich plötzlich deine Ideen aufgreifen
und voller Begeisterung mitmachen. Also, dieser Forming-Gedanke, dieses
ich kann das am grünen Tisch machen und irgendwie zusammenbasteln, der funktioniert da nicht.
Und es gibt auch in dem ganzen Umfeld so richtig toxische Ideen.
Also, zum Beispiel wird oft gesagt, man muss die Menschen da abholen, wo sie stehen.
Das ist absolut toxisch.
Also, ich meine, warum muss ich überhaupt jemanden abholen, wo er steht?
Doch nur, weil ich ihn dort stehen gelassen habe.
Also, wenn er die ganze Zeit bei mir war, wenn ich die ganze Zeit mit ihm im Gespräch war,
wenn er sozusagen gehört wurde die ganze Zeit, dann steht er nicht irgendwo, wo ich ihn abholen müsste.
So quasi zurückgeblieben noch. Also, das fehlt gerade noch, dass man das so ausdrückt.
Sondern ich habe proaktiv etwas getan und dann bin ich auch nicht dabei verzweifelt,
mir zu überlegen, wie ich jetzt das Team forme und bilde,
sondern ich kann den Input von ihm erwarten oder von ihr, weil die eben die ganze Zeit schon mit dabei waren.
Ja, und das Abholen suggeriert ja auch, dass ich weiß, wo vorne ist.
Also, vielleicht müsste er mich ja abholen und in die andere Richtung gehen, oder?
Ja, vielleicht müsste er mich einfangen, ja. Das wäre dann natürlich…
Oder einhören.
Ah, ja, einhören. Ja, okay, gut.
Also, wenn ich das mal so zusammenfasse, du sagst eben eher gerade das Formen,
das muss eher von innen, also gerade das Formen muss von innen passieren.
Dann hast du ein paar alternative Modelle eben angesprochen,
da können wir vielleicht nachher nochmal ein bisschen drauf eingehen.
Aber die Frage, wenn das jetzt hier nicht so gut ist, was gibt es denn Besseres?
Oder nutzt man das nur, weil es nichts Besseres gibt?
Also, vielleicht haben wir ein paar alternative Modelle.
Lassen wir uns noch ein bisschen bei diesen Phasen bleiben.
Jetzt haben wir eben gesagt, Forming kommt von innen.
Was ist, wenn es überhaupt nicht funktioniert?
Also, wenn es wirklich andauernd Storming gibt, wenn es andauernd kracht?
Mhm.
Ja, also Storming im Sinne vom Taktman ist ja Widerstand gegen die Unterordnung oder die Gruppe
und gegen neue Herangehensweisen.
Und wenn es jetzt ständig stormt und kracht, dann wäre so rein im Effizienz-Sinne der erste Gedanke bei mir,
ist das überhaupt ein Konflikt der Gruppe?
Oder drückt sich da jemand von außen, jemand, der außenstehend ist,
um eine Konversation oder eine Entscheidung herum und erwartet dann, dass die Gruppe das für ihn trifft oder für sie?
Ja, jeder Programmierer kennt das.
Also, wenn du vor der Tastatur sitzt, dann kannst du nur das programmieren, was die Maschine auch versteht.
Also, du musst die Entscheidung treffen.
Also, wenn jetzt irgendein PO oder sonst wer eine Entscheidung nicht treffen will,
dann spätestens musst du sie an der Tastatur treffen.
Und wenn dir ständig jemand solche Entscheidungen weiterschiebt, obwohl sie gar nicht zu dir gehören,
dann musst du halt irgendwann auch mal Nein sagen.
Also, von daher, wenn es ständig stormt, wäre das so die erste Frage, ob ich mich überhaupt darüber kümmern sollte
oder ob ich nicht zu dieser betreffenden Person gehen sollte.
Wenn ich einen Scrum Master habe, mit dem Scrum Master mal darüber rede,
ob der nicht mit der Person ein bisschen tacheles redet,
dass doch bitte ich diese Konflikte, die weit über meinen Horizont oder über meinen Arbeitsbereich rausgehen,
nicht stellvertretend für die Person lösen kann.
Umgekehrt, wenn ich jetzt aber sage, okay, der Konflikt ist jetzt im Team
und das ist definitiv der Konflikt des Teams und nicht von irgendjemand anders,
dann stellt sich für mich die Frage, wie die Gruppe damit umgehen will.
Übrigens, ganz witzig, Tuckman selber redet nur von Gruppen, der redet gar nicht von Teams.
Team taucht nur zweimal auf in seinem Paper und da auch nur als Zitat, also er redet immer von Gruppen
und die sind bei ihm auch bis zu 30 Personen groß.
Aber okay, also angenommen, ich habe jetzt den Konflikt in der Gruppe und die Gruppe sagt, ja, ist unsere.
Nicht jemand anderes.
Dann ist für mich der nächste Schritt zu fragen, wie will die Gruppe damit umgehen?
Womit ist sie zufrieden?
Will sie Probleme recyceln oder will sie sie nur entsorgen?
Und das ist ein ganz wichtiger Unterschied.
Also.
Also ein bisschen so, wie wenn ich im Garten jetzt Maulwurfshügel habe.
Also ich kann mit der Schaufel rumlaufen und die platt klopfen.
Das, was man im Englischen so schön Mow-Wacking nennt.
Und dann taucht am anderen Ende vom Garten wieder so ein Haufen auf.
Ich klopfe also ständig nur Probleme platt und ärgere mich dann darüber.
Aber ich werde toll für meinen Garten gelobt, weil ich bin ja ein toller Maulwurfshügel-Plattklopfer
und bei mir ist der Garten immer so schön flach.
Das ist ein reines Entsorgen von Problemen.
Also ich will weniger Probleme, weniger Probleme, weniger Probleme.
Das heißt, kann ich aber auch ein bisschen mehr Ansprüche stellen und mich dann fragen.
In Problemen steckt ja eine Menge Energie drin.
Wenn ich stinkesauer bin über etwas und mit etwas nicht fertig werde,
dann ja nur deswegen, weil ich genau weiß, was ich stattdessen will.
Das ist also eine Frage, ob ich das Team an der Stelle dazu kriege,
darüber zu diskutieren, was seine Identität ausmacht und wo es hin will.
Das ist jetzt auch nicht wirklich so eine mordsmäßig herausfordernde Aufgabe,
weil wir das eigentlich können im Alltagsleben.
Also es ist eher umgekehrt so, wenn wir jetzt zum Beispiel unseren Urlaub so planen würden,
wie wir unser Berufsleben planen würden.
Dann würden wir so Sachen sagen wie,
ja, also ich möchte eine Anreise ohne Stau und ohne Fluglotsenstreik
und ich möchte aus dem Fenster nicht auf die Wand vom Nachbarhotel gucken
und ja, in den Badecken soll es nicht schimmeln
und am Frühstücksbuffet sollen die Schalen nicht leer sein.
Es plant kein Mensch seinen Urlaub so, sondern du guckst, was du willst.
Also du willst einen bestimmten Ausblick haben.
Du gehst nicht in irgendein Hotel, wo sie irgendwelchen Touristenmampf servieren oder so etwas.
Also wir haben das schon drauf, nur gehen wir mit unserer Arbeitsumwelt
komischerweise so um, als ging es immer nur darum, ja, Probleme zu lösen.
Und das ist halt ein bisschen…
Ja, okay. Also zum Beispiel mit dem Maulwurfshügel, das finde ich sehr, sehr cool.
Also das kommt auf jeden Fall auch in die Beschreibung,
damit die Leute interessiert werden, was Maulwurfshügel mit DevOps-Teams zu tun haben.
Ja, ich finde es auch interessant, was ich da immer so ein bisschen raushöre,
ist etwas, was bei mir ziemlich hängengeblieben ist von einem Buch, das ich vor einer Weile gelesen habe.
Turn the Ship Around hieß das, wo der Autor auch mal darauf eingeht,
dass irgendwie, da ging es irgendwie um Metriken und Fortschritt messen und so was.
Und er hat gesagt, er kam auf dieses U-Boot, er war irgendwie ein U-Boot-Captain,
und alle Metriken waren irgendwie ausgerichtet auf Vermeidung von Problemen.
Es gab dann, wie viele Tage seit dem letzten schweren Unfall und solche Sachen.
Und er hat gesagt, das ist ja okay. Ich meine, niemand will Unfälle haben.
Aber wenn du immer nur darauf achtest, nicht nach unten zu rutschen, dann kommst du halt nie nach oben.
Einfach, weil du die Blickrichtung gar nicht hast. Du bist immer nach hinten gewandt.
Du bist immer auf Vermeidung ausgerichtet und nicht auf Vorwärtsbewegung, auf Fortschritt, auf Weiterentwicklung.
Das ist irgendwie so das, was ich bei dir immer wieder gehört habe und was bei mir jetzt gerade hängengeblieben ist.
Ich finde das interessant.
Ja, das ist eher so ein lösungsfokussierter Ansatz. Das wird oft missverstanden als positives Denken.
Also auch morgens ein Joint und der Tag ist dein Freund.
Und dann kommst du dem Tag ins Gesicht und solche Sachen, was eigentlich nicht der Sinn der Sache ist.
Also der Punkt an der Stelle ist, dass es ein strategischer Ansatz ist.
Wenn du sowieso schon weißt, dass du den Tag nicht zu Ende kriegst und alle Probleme vom Tisch bekommst, dann weißt du, dass irgendwas hinten runterfällt.
Und wenn das so ist, dann sorgst du doch am besten dafür, dass die unwichtigen Sachen runterfallen.
Das kannst du aber nicht, wenn du mit dem Problemanalysieren anfängst.
Also wenn du irgendwo stehst und dann alle Problemsteinchen, Felsen um dich sammelst, die da so rumliegen und die anguckst,
dann bist du vielleicht ein guter Troubleshooter.
Und alle Leute klopfen dir auf die Schulter, weil du ja so toll Troubleshooten kannst.
Aber du machst nichts wirklich strategisch Sinnvolles.
Also ist es geschickter, wenn du das erst rumdrehst und dir überlegst, in welche Richtung will ich ungefähr gehen?
Wo wird es ein bisschen heller, als es jetzt so ist?
Und dann brauchst du dich auch eher nur um die Probleme kümmern, die auf dem Weg dorthin liegen, anstatt um alles und jedes, was um dich rumliegt.
Du musst halt den Mut haben, dann auch zu sagen, ja, stimmt, dieses Problem konnte ich nicht lösen.
Aber aus strategischer Sicht ist das jetzt auch nicht wirklich zielführend, wenn ich mich nur um Probleme kümmere.
Und mir gar keine inhaltlichen oder strategischen Fragen stelle.
Was anderes, was ich mich auch noch gefragt habe, als ich dich habe reden hören über diese Storming-Geschichte,
spielt das denn überhaupt eine Rolle, ob die Missstimmung, die vielleicht herrscht in einem Team,
ob die persönlich begründet ist oder ob die sachlich begründet ist?
Das ist eine sehr gute Frage, weil ich würde mal sagen, die meisten Teams arbeiten in einem sehr komplexen Umfeld.
Und das beides da auseinanderzuhalten, wird schon sehr, sehr schwierig.
Also der Punkt ist ja, warum es so einfach ist, Zoff mit anderen Menschen anzufangen, ist ja, dass wir erleben, dass der Problemfokus in einem komplizierten Umfeld gut funktioniert.
Wenn ich mich durch einen Quellcode durchdebugge oder wenn ich ein kaputtes Auto repariere, dann kann ich das analysieren, auseinanderlegen, zusammenbauen und nichts ändert sich.
Also das ganze System bleibt gleich, bis ich tatsächlich aktiv was mache.
Und es gibt auch natürlich die Wurzelursache allen Übels, die ich finden kann und beseitigen kann.
Wenn ich durchdebugged habe und den Fehler rausmache, dann ist der Fehler weg.
Wenn ich das Auto repariert habe, dann fährt es wieder.
Das ist eine sehr erfolgreiche Strategie, sich also voll und ganz auf das Problem zu konzentrieren.
Funktioniert auch sehr gut in einem komplizierten Umfeld, also wo es nur um Maschinen geht quasi.
Im komplexen Umfeld, also sobald ein Mensch ins Spiel kommt oder wenn es um ein Ökosystem geht oder alles was komplex ist, funktioniert es eben nicht,
weil da so viele Faktoren im Spiel sind, die sich gegenseitig beeinflussen, dass es keine Wurzelursache des Übels mehr gibt.
Und das Fatale ist, wenn ich jetzt vorm Rechner sitze und gewohnt bin, dass es ja super erfolgreich ist, etwas zu debuggen,
dann fange ich auch an zu versuchen, Menschen zu debuggen.
Also das Auto oder der Quellcode nimmt es mir nicht übel, wenn ich davor sitze und sage, hey, du bist kaputt und ich weiß genau, wie ich dich repariere.
Probier das jetzt mal mit einem Kollegen oder mit einer Kollegin.
Das ist nicht sehr erfolgversprechend und es ist auch innerlich ansatzmäßig falsch.
Ich stelle mir das gerade vor, wenn der Coach schon da sitzt.
Also du hast dein Problem.
Ob du willst oder nicht, ja.
Also an der Stelle muss man sich eben spätestens entscheiden, wenn man schon weiß, dass man im komplexen Umfeld arbeitet,
will ich tatsächlich effektiv sein oder will ich nur mit meiner Diagnose recht haben?
Also ein richtiges Team zeichnet sich dadurch aus, dass sie sich zusammenraufen und sagen, wie können wir effektiv werden an der Stelle?
Und eine Arbeitsgruppe zeichnet sich eher darüber aus, dass jeder dem anderen schon die passende Diagnose gestellt hat
und nur darum geht, zu beweisen, dass die Diagnose richtig war, um dann am Ende sagen zu können,
ja, wenn alle nur auf meine Diagnose gehört hätten oder wenn sie jetzt endlich ihr Verhalten ändern würden,
dann könnten wir Fortschritte machen.
Aber ja, geht ja leider nicht, weil keiner auf mich hört.
Ihr hört ja nicht auf mich.
Ja, genau.
Arbeitsgruppe und Team, da wollte man noch eingehen.
Du hast jetzt schon ein paar Punkte genannt, woran man das unterscheidet.
Kannst du vielleicht das noch ein bisschen tiefer fassen?
Also wo kann man, also natürlich nicht so von wegen, ich gucke mir so ein Team an und dann erkenne ich nach zwei Minuten, das ist eine Arbeitsgruppe.
Hast du zwar gesagt, wenn du dir auf das Board alles anschaust, geht das.
Also wo sind Unterschiede zwischen einer Arbeitsgruppe und einem Team?
Ja, also ich würde das jetzt nicht so generell verteufeln wollen, wenn ich eine Arbeitsgruppe sehe.
Also jedes Team ist auch eine Arbeitsgruppe und nicht jede Arbeitsgruppe ist ein Team.
Nur wird heute relativ selten irgendwo das Label Arbeitsgruppe draufgelegt.
Sondern immer das Label Team.
Ich denke, es hat schon gewisse Grenzen, was die Anzahl der Mitglieder angeht.
Also nicht umsonst propagiert man ja bei agilen Teams so eine Faustregel von sieben plus minus zwei Leuten.
Ob das jetzt wirklich so streng zu nehmen ist, ist noch die Frage.
Aber eine Teamidentität kann sich in größeren Gruppen jetzt nicht wirklich ausbilden.
Das Modell ist jetzt zahlenmäßig schon ein bisschen begrenzt.
Und es ist schon so, dass es in Arbeitsgruppen tendenziell mehr Diskussionen gibt über Zuständigkeiten und Interfaces und Übergaben und ähnliches.
Was ein bisschen eine heikle Geschichte ist.
Also in einem Team kannst du mehr mit Verantwortungsgefühl arbeiten.
Das ist halt das, was im Englischen…
Man kann es im Englischen gut ausdrücken.
Im Englischen ist es Responsibility im Vergleich zu Accountability.
Also Responsibility ist, ich bin in der Lage, eine Antwort zu geben auf die Situation vor mir.
Kann jeder im Team und kann jeder auch 24 Stunden am Tag oder acht Stunden am Tag innerhalb der Arbeitszeit.
Accountability ist, wenn man es wörtlich nimmt, die Fähigkeit, einen Account zu geben, also einen Rechenschaftsbericht.
Das wird nicht 24 Stunden am Tag von dir verlangt, sondern irgendjemand will das in größeren Abständen von dir hören.
Da darf selbstverständlich auch nur einer den Rechenschaftsbericht ablegen.
Das heißt also, Accountability ist von sich aus schon mal nicht auf diese Effektivität ausgerichtet.
Also es geht nicht darum, dass du tatsächlich dein Ziel erreichst, sondern du musst nur in der Lage sein, zu erklären, ob du es erreicht hast und wenn ja und wenn nein, warum.
Das ist der Sinn von Accountability.
Also auch der, der den Bericht dann bekommt, der will ja nicht die ganze Zeit mit dem Thema beschäftigt sein und Präsenz zeigen, sondern der will sozusagen nur in regelmäßigen Abständen hören, ob es läuft oder nicht und wenn ja oder wenn nein, warum.
Und ob da auch so eine rote Ampel drauf ist zum Beispiel, also dann muss er ja was tun.
Ja gut, gibt ja auch den Melonen-Statusbericht außen grün und innen rot.
Ja, aber der Knackpunkt an der Stelle ist, in einem Team fragst du nach einer Weile nicht mehr, also du verschwendest nicht den Hauptteil deiner Zeit damit zu diskutieren, wie die Zuständigkeiten aussehen.
Also das ist, als ob ich jetzt quasi beim Fußball auf der Torlinie stehe.
Ich bin nicht der Torwart, der Ball kullert an mir vorbei, ich lasse ihn ins Tor und sage dann dem Torwart, ja du, also das ist ja echt wirklich dein Zuständigkeitsbereich, wie konntest du nur den Ball reinlassen?
Und so Kolleginnen und Kollegen braucht Männer, nicht im Team.
Brauche ich wirklich nicht.
Dieses Vertrauensverhältnis, dass sozusagen einer was machen darf, was eigentlich gar nicht in seinen Zuständigkeitsbereich gehört, das entwickelt sich auch erst, das muss man sich verdienen.
Also wenn dieses Verantwortungsgefühl und dieses Vertrauen, dass jemand anders eine Rolle spielen darf, dem gar nicht zukommt.
Also dann muss erstmal sozusagen diese Sucht nach Accountability, diese Sucht, jemanden mit dem Hals umdrehen zu können, die muss ein bisschen verschwinden und das geht nur über Vertrauen, also das muss man sich hart verdienen.
Okay.
Ja, dann lass uns mal noch ein bisschen über die alternativen Modelle sprechen. Oder hast du noch Fragen zum Thema Tuckman, Luca?
Ich hatte vorhin eine, aber sie ist mir wieder entfallen. Mal schauen, ob sie mir wieder einfällt.
Na, kommt mal. Wir haben noch ein bisschen Zeit.
Die Phase ist noch nicht da.
Du hast ein paar alternative Modelle genannt, also zumindest habe ich eben so zwei deinen Namen gehört. Kannst du da mal ein bisschen was dazu sagen?
Ja, also es haben sich ja schon ein bisschen mehr Leute Gedanken darüber gemacht, wie man heutzutage mit Teams umgeht.
Also der Startpunkt ist ja, was du wirklich willst von einem Team, ist ja das Engagement von den Leuten und auch als Team.
Aber wirkliche Kontrolle hast du nur über die reinsten Olsen.
Also als Team geht wahrscheinlich noch nicht mal über die Arbeitszeit. Du kannst den Leuten nicht sagen, du bist um 9 Uhr da und um 5 Uhr gehst du wieder.
Also wirklich kontrollieren oder managen kannst du nur die reinen Äußerlichkeiten, aber was du wirklich willst, ist das Engagement.
Und von daher kannst du, wenn du das einmal erkannt hast, nicht mehr auf der Schiene arbeiten, dass du das jetzt irgendwie ja quasi mit großen Leadership-Theorien versuchst zu erreichen.
Also Leadership hat ja per se schon mal die Schwäche, dass man die Metapher gar nicht mehr weiterlebt.
Und die Metapher gar nicht mehr wirklich verstehen kann.
Sagt ja auch jeder. Also es will keiner, dass einer vorangeht und alle anderen gucken ihm auf den Rücken und dackeln hinterher die Follower dann.
Das will keiner mehr. Also selbst Leadership-Autoren schreiben als allererstes, nee, so ist das ja gar nicht gemeint.
Ich finde andere Metaphern viel hilfreicher, die sind ein bisschen universeller und positiver.
Also ich finde zum Beispiel Host Leadership, das ist ein Buch von Mark McKerger und Helen Bailey, sehr schön, weil es diese Metapher des Gastgebens ausweitet auf Organisationen,
Gruppen, Teams und wie man damit zu Rande kommt.
Also es nimmt sozusagen die Rollen, die ein Host spielen kann, also initiieren, einladen, Räume gestalten, Gatekeeping, Verknüpfungen schaffen, mitmachen auch bei dem Ganzen
und wendet es an auf die Arbeit mit Teams und Mitgruppen.
Auch die Positionen, die ein Host einnehmen kann, also Gastgeber, wenn man es jetzt ganz wörtlich nimmt, kann im Rampenlicht stehen, kann bei den Gästen sein, kann auf der Galerie stehen, runtergucken auf das Geschehen,
was sich da so eignet oder kann in der Küche etwas werkeln.
Das lässt sich auch von der Metapher her sehr gut übertragen auf deine Arbeit, das, was man normalerweise Führungsarbeit nennt.
Und ein ganz wichtiger Punkt noch bei Host Leadership ist auch diese interessanten Moves zwischen Stepping Forward und Stepping Back.
Also was normalerweise Führungskräfte sehr gut drauf haben, ist so nach vorne treten, Initiative ergreifen, Hurra, Vision, Mission und so weiter propagieren.
Was aber ein bisschen zu kurz kommt, ist dieses Stepping Back.
Also meine eigene Initiative zurücknehmen und dann den Raum anderen lassen, um selbst den Luft zu lassen.
Also was Gregory Bateson so schön ausgedrückt hat, spot useful change and amplify it.
Das ist auch mein Job.
Also es bin nicht ich, der immer alles initiiert, sondern es ist auch genauso mein Job, rumzugucken, nützliche Veränderungen auszumachen und dann die zu fördern.
Nicht zu hijacken, also dass ich das Ganze dann gleich übernehme und es unter meinen Namen läuft,
sondern dass ich sozusagen auch der Person den Support gebe, das selber eigenständig voranzutreiben.
Das ist das, was man aus Host Leadership lernen kann. Ganz tolles Buch.
Es ist, wie gesagt, übertragen von einer Metapher auf die Führungsarbeit.
Also man sollte da keine Kochrezepte erwarten, sondern es ist einfach nur etwas, was man natürlich und intuitiv verstehen kann,
was wesentlich weniger erklärungsbedürftig ist als Leadership. Ich weiß nicht, warum das Wort Leadership überhaupt drinsteht,
aber weil Host ist selber schon eine sehr starke Metapher. Ist aber ein sehr nützliches Buch.
Du wolltest jetzt ein zweites Modell ansprechen, richtig?
Ja, es gibt noch mehr. Also was wahrscheinlich jetzt, weil es gerade sowieso in Mode ist, den meistens schon geläufig ist, ist das Carnarvon-Modell.
Also dass man unterscheidet zwischen den Domänen, in denen man sich bewegt, die klar sind, kompliziert, komplex, chaotisch oder konfus.
Das würde jetzt ein bisschen zu weit führen, wenn man das alles ausführt. Nur so viel, nicht jede Strategie, die in einem von diesen Bereichen funktioniert,
funktioniert halt auch in den anderen. Wir hatten es vorhin von kompliziert versus komplex.
Wenn ich also mein Programm debuggen kann und dem Programm sozusagen sage, ich weiß, was mit dir nicht stimmt, dann heißt das noch lange nicht,
dass es im komplexen Bereich, also im Teamwork, einem meiner Kollegen oder Kolleginnen an den Kopf werfen kann und es dann auch funktioniert.
Ja, okay.
Das kann man also aus Carnarvon lernen.
Was vielleicht auch noch ganz nützlich ist, ist,
das ist etwas, was aus dem Bereich der Pädagogik kommt, das Konzept der New Authority, neue Autorität.
Das ist von einem israelischen Pädagogen entwickelt, Chaim Omer, und beschäftigt sich schwer mit der Präsenz einer Person als Anzeichen von, auf Englisch, Care.
Deutsch kann man es nur relativ übel übersetzen mit Fürsorge. Also das klingt ein bisschen betreuungsmäßig auf Deutsch.
Aber der Grundgedanke ist genau das gleiche.
Das ist ganz einfach.
Du musst es hinkriegen, dass deine Anwesenheit als ein Zeichen von Fürsorge gesehen wird.
Das ist auch etwas, was ich leider häufig erlebe, dass mir manche Führungskräfte sagen, sie trauen sich gar nicht so richtig, sich mal in eine Sitzung reinzusetzen oder so,
weil dann schrillt so der Bossalarm los.
Warum ist der da? Was haben wir falsch gemacht? Und so weiter.
Und das ist sehr, sehr schade, weil diese Präsenz ist etwas sehr Wichtiges und du kannst sie eigentlich nur dann leben, wenn du gewöhnt bist, die Position zu wechseln.
Also wenn ich jetzt mal gleich rüber übertrage auf die Host-Leadership-Perspektive.
Wenn du immer nur in der Küche sitzt, weil du halt lieber still vor dich hin werkelst als Führungskraft, dann entgeht dir was.
Du musst auch mal raus und unter die Gäste gehen. Du musst auch mal im Rampenlicht stehen und eine Ansage machen.
Also Präsenz kann nicht wirken, wenn du immer nur am gleichen Ort bleibst. Du musst dich also bewegen und du musst irgendeinen Weg finden, dich bewegen zu können.
Also da kann man auch aus dem Bereich New Authority sehr viel noch rausschöpfen.
Und was in dem Bereich auch noch sehr stark propagiert wird, ist, dass auch die Führungsriege sich als Team versteht.
Das ist ja auch noch eine sehr große Baustelle bei uns. Also man verlangt zwar von den eigenen Teams natürlich Teamwork und Team Spirit,
aber man ist selber nicht in der Lage auf der Führungsebene dann Probleme eben so ganzheitlich zu betrachten und sich selber als Team zu sehen.
Mhm, ja. Sehr, sehr interessant. Gerade eben auch das Thema eben Team oder Management Team.
Wenn man da als Coach Einblick hat, wie es da funktioniert oder nicht funktioniert, ist das schon sehr, sehr hilfreich, auch dann die Teams zu verstehen.
Oder eben genau zu verstehen, warum Teams nicht funktionieren. Okay.
Gut, jetzt bin ich aber doch neugierig. Nämlich, wenn ich jetzt das Gefühl habe, ich habe da jetzt irgendwie einen Haufen Leute und ich möchte gerne, dass die mehr ein Team werden.
Wie kann ich das denn erreichen? Und ich meine, die eine Frage ist, wie kann ich das denn machen als Chef gegenüber meinen irgendwie Untergebenen,
denen ich vielleicht auch irgendwie sehr fürsorglich gegenübertreten will?
Aber genauso spannend ist doch auch die Frage, wie mache ich das in die umgekehrte Richtung?
Wie kann ich denn meine Chefs dazu bringen, dass die sich irgendwie mal am Riemen reißen?
Ah, jo. Ich würde mal sagen, das hängt schwerstens von der Persönlichkeit von deiner Chefin oder von deinem Chef ab.
Also, ja.
Ich traue mich da, ich bin ja auch als Facilitator und teilweise als Coach unterwegs, ich traue mich da auch keine generellen Rezepte anzugeben.
Der Punkt ist, dass es sich am meisten auszahlt, gemeinsame Ziele zu finden.
Also, ich würde mich nicht unbedingt mit Streitthemen aufhalten, in denen sich gewisse Ängste ausdrücken.
Das ist klar, die verstehe ich, aber ich würde von vornherein versuchen, diesen lösungsorientierten Twist hinzubekommen.
Also, wenn du, es gibt eine schöne Übung im Lösungsfokus, die heißt Probleme in Ziele verwandeln.
Wenn also eine Situation festgefressen ist, also egal, ob du jetzt Probleme mit deinem Chef hast und den sozusagen irgendwie positiv beeinflussen willst oder ob es im Team Probleme gibt.
Du machst das mal im Brainstorming und schreibst auf der einen Seite von einem Blatt Papier die ganze Liste von Problemen runter, bis dir nichts mehr einfällt.
Da kannst du schon eine halbe Stunde damit verbringen manchmal.
Alles raus, alles raus, alles raus.
Dann holst du mal tief Luft, machst vielleicht einen 10-Minuten-Spaziergang, ziehst in der Mitte von einem Blatt einen Strich und schreibst auf die rechte Seite,
was wünsche ich mir stattdessen?
Wovon wünsche ich mir stattdessen mehr?
Also auf der linken Seite steht alles, wovon du weniger haben willst.
Auf der rechten Seite steht, wovon du mehr haben willst.
Und auf der Basis kannst du mit einer Führungskraft wesentlich schneller auf einen gemeinsamen Draht kommen, als wenn du jetzt ständig über Probleme redest.
Weil bei Problemen geht es nur um weg, weg, weg, weg, weg damit und du hast keine Chance, auf gemeinsame Ziele zu fokussieren.
Und das Witzige dabei ist, dass die gemeinsamen Ziele eigentlich dann sehr, sehr viele von diesen Problemen subsumieren.
Also sozusagen, wenn du das erreicht hast oder da mehr Wert drauf legst,
dann hat das auch gleich einen positiven Einfluss darauf, diese Probleme zum Verschwinden zu bringen, langsam.
Also ich würde auf jeden Fall hier eher einen lösungsfokussierten Weg anschlagen.
Und ich würde auch davon ausgehen, dass jeder, also jedes Mitglied in einem Team und auch jeder Chef Experte auf seinem Gebiet ist.
Also ich würde versuchen, schleunigst aus dem Diagnosemodus rauszukommen.
Der Chef ist ein arroganter Fiesling oder sonst was, damit komme ich nicht weiter.
Also es gibt solche Sonderfälle, natürlich.
Es gibt natürlich auch Psychopathen, die Chefs geordnet haben.
Nur beschäftigt sich viel von dem, was man so auf Twitter liest oder so mit diesen Sonderfällen.
Und das ist so, als ob ich sagen würde, 99% meiner Kolleginnen und Kollegen sind Arschlöcher.
Das stimmt nicht. Umgekehrt.
99% meiner Kolleginnen und Kollegen sind eigentlich ganz okay.
Selbst wenn ich Stress mit denen habe, komme ich wieder ins Reine mit ihnen.
Und es gibt 1% Arschlöcher.
Und dann ist eben die Frage, ob ich mein Regelwerk an diesen 1% Arschlöchern ausrichten will oder an den 99%, mit denen ich klarkomme.
Und wenn ich mir stattdessen die Welt so einrichte, dass mein Chef halt ein Tyrann ist
oder ein Autokrat oder sonst was, dann kriege ich auch das genau zurückgespiegelt.
Weil ich bemühe mich ja nicht mal auf einen gemeinsamen Länder zu kommen, gemeinsame Ziele zu finden.
Zumal ja auch, selbst wenn du mit deiner Diagnose völlig richtig liegst, ist die Frage, was hast du davon?
Ja, in gewissen Fällen musst du es dann schon machen.
Also ich war ja auch einige Jahre jetzt als Führungskraft tätig, bevor ich mich dann selbstständig gemacht habe und nur noch mich selber führen musste.
Und es gibt schon Fälle, wo du nicht weggucken darfst.
Also übergreifend.
Und diese Begriffigkeiten kannst du einfach nicht tolerieren.
Du kannst nicht tolerieren, wenn Leute sich wirklich, ja, wenn du quasi einen Stalker irgendwo in deinem Team hast.
Also es gibt schon Extremfälle, wo du dann schleunigst eingreifen musst, die Grenzen ziehen musst und auf die Leute hören musst,
die sich da betroffen und verängstigt fühlen.
Also das ist das Schlimmste, was man machen kann, wenn man dann noch versucht, irgendwie so einen positiven Twist hinzugeben.
Ja, red doch mal mit dem oder so.
Nee, muss ich an der Stelle nicht.
Also in diesen Extremfällen musst du Klartext reden.
Und auch der Person glauben, die da zum Opfer geworden ist.
Ja, ich habe mal ein Interview gelesen mit einer irgendwie Führungskräfte, Therapeutin oder sowas, die genau in solchen Streitsituationen gerufen wurde.
Und die hat haarsträubende Geschichten erzählt von Leuten, die sich gegenseitig angespuckt haben und sowas.
Da kann man ja da hart nicht erst sagen, vertragt euch doch wieder.
Ja, es gibt übrigens ein schönes Buch von Wilhelm.
Von Veronika Kotroba und von Ralf Mejaka. Agile Teams, lösungsfokussiert coachen.
Wo sie auch ein schönes Kriterium dafür geben, ab wann man sich spätestens Hilfe holen soll.
Sie nehmen die Skala von Glaser, der also so die Eskalationsstufen von Konflikten ein bisschen modelliert hat.
Und das sind ja drei große Bereiche im Prinzip.
Wenn man sich im Win-Win-Bereich bewegt, dann können die noch miteinander.
Wenn ich mich im Win-Lose-Bereich bewege, dann heißt das, ich gewinne, du verlierst beim Streiten.
Und wenn man sich im Lose-Nose-Bereich bewegt, dann geht’s den Bach runter und es ist mir egal.
Hauptsache ich reiß dich mit.
Sobald man den Win-Win-Bereich verlässt, wird es vielleicht Zeit, dass man sich überlegt, ob man jetzt wirklich noch mit so einem freundlichen Gespräch weiterkommt.
Das ist übrigens auch noch so ein Buch, was ich schwerstens empfehlen kann. Agile Teams, lösungsfokussiert coachen.
Sehr, sehr hilfreich. Und es ist vor allem ein sehr schönes Runterbrechen der lösungsfokussierten Methode auf das agile Teamwork.
Können sich auch DevOps davon profitieren.
Ja, also die Empfehlung kann ich unterstützen. Steht bei mir auch im Schrank und ist sogar auch schon teilweise gelesen.
Also ich muss immer wieder auf Lukas Stapel der Schande, muss ich immer zurechtkommen.
Hat meine Arztpraxis aufgelegen, aber aktuell, ja, ich habe ein bisschen was rausgezogen und finde ich auch sehr, sehr interessant und auch sehr, sehr hilfreich.
Kommen wir ein bisschen zu dem Punkt, wo ich vorhin noch überlegte, was zu sagen.
Vieles von dem, was du heute gesagt hast, findet man wahrscheinlich auf deiner Webseite, richtig?
Tendenziell eher wenig, weil das sind jetzt nicht unbedingt Ideen, die ich mir auf die eigenen Fahnen schreiben möchte.
Also der Punkt, wenn du Host Leadership nachschauen willst, schaust du einfach auf hostleadership.com.
Marc und Helen haben ihre eigene Webseite und es gibt auch des Öfteren so quasi abends Mini-Einführungskurse, die dann auch auf LinkedIn und auf Twitter entsprechend verkündet werden, wo man sich relativ schnell mal informieren kann.
Ich bin da so auch bei den Stewards dabei.
Und helfe damit, sowas zu organisieren.
Mache ich auch selber teilweise solche Intros.
Von daher ist es eigentlich besser, wenn man die Begriffe selber googelt.
Bei Carnavin ist es sowieso ein bisschen schwierig.
Wir wissen ja alle, dass Dave Snowden immer noch kein Buch geschrieben hat.
Es gibt immer noch keine Einführung dazu.
Bleibt also nichts anderes übrig, als einen Blog zu lesen.
Und das ist, ja, Softwareentwickler wird das vertraut vorkommen.
Also du fängst beim Startpunkt an und arbeitest dann die Diffs ein, je weiter du dich aktuell nach vorne liest.
Das ist sehr, sehr mühsam.
Ich hätte liebend gern mal ein Buch.
Aber wenn du was über Carnavin rausfinden willst, musst du das quasi dort nachlesen.
Host Leadership auf Deutsch. Dazu habe ich was geschrieben.
Also hostleadership.de.
Da habe ich einen kleinen Post drauf, was Host Leadership eigentlich bedeutet.
Also da kann man schnell einen Überblick gewinnen.
Bei New Authority schaut es im Moment noch schwach aus in Deutschland.
Also da musst du wahrscheinlich ein englisches Buch dir raussuchen von Kai Moomer.
Beziehungsweise von einem seiner Schüler oder Schülerinnen.
Und da gibt es in Deutschland noch relativ wenig.
Es gibt ein Buch von, oh, da fällt mir jetzt der Name nicht ein.
Und auch der Titel natürlich nicht.
Lass mal überlegen.
Nein, ich komme jetzt nicht drauf, weil ich es auch schon vor längerer Zeit gelesen habe.
Aber es wendet die New Authority auf Führungsarbeit an.
Und da gibt es auch, ich schicke dir das, glaube ich, nachher noch als Link.
Dann kannst du das vielleicht in die Shownotes mit reinpacken.
Das wollte ich gerade sagen, weil das war so gerade der Versuch, den Übergang zu schaffen,
was man in den Shownotes seiner Webseite findet.
Jetzt hast du sehr, sehr schön argumentiert, dass man das nicht bräuchte.
Ich frage nochmal, wer Informationen braucht, wem deine Aussagen gefallen haben,
der kann auf seiner Webseite ein bisschen was von dir finden.
Mindestens eine Telefonnummer.
Der kann mindestens eine Telefonnummer finden, aber eigentlich auch einmal eine E-Mail-Adresse.
Und es ist wahrscheinlich leichter, mich asynchron zu erreichen.
Ich bin auch durchaus gegen Geld zu haben.
Du bist auch käuflich, so ein bisschen.
Ich bin käuflicher, genau.
Gut. Luca, hast du noch ein paar Fragen?
Nein, aber ich fand das ganz toll. Ich bin momentan ganz begeistert.
Ich fand es spaßig, mit euch zu diskutieren und auch eure Fragen zu bestimmten Punkten zu hören,
weil es ist immer wieder witzig, in welche Lücken ihr so reinfragt,
wo ich mir selber noch nicht ganz so viele Gedanken drüber gemacht habe.
Wo ich mir jetzt auch wieder ein paar Gedanken machen werde. Dankeschön.
Ja, das freut mich. Ich bin mir auch nicht zu schade, dumme Fragen zu stellen.
Du weißt doch, es sind keine dummen Fragen.
Richtig. Und ich bin auch gerne bereit, so ein bisschen zu pricken.
Ich finde gerade das passende Wort nicht ein.
Ich finde es ein bisschen, Leute zu pieken, das ist vielleicht noch mal ein bisschen besser.
Also wirklich mal so nachzufragen, dass meine Frau manchmal auch sagt,
Mensch, Alter, das geht zu weit. Na ja, egal.
Gut. Gibt es noch Punkte von dir, Rolf, die du noch ansprechen wolltest,
die dir so zum Abschluss noch einfallen?
Ja, was hätten wir denn fragen sollen?
Es wurde alles gefragt.
Weiß ich nicht. Also vielleicht noch umgekehrt ein Kompliment zu dem Podcast.
Also ich mag den Grundgedanken von DevOps, mag ich schon sehr gerne.
Und was mir vor allem gut daran gefällt, ist der Respekt für andere Leute, für andere Teams.
Also dass du gerade das nicht machst, zu glauben, da wäre eine Mauer und du schmeißt einfach irgendwas rüber.
Also dass dir wirklich wichtig ist, durchgehend nachhaltig irgendwie gute Ergebnisse zu liefern.
Und es dich dann auch juckt, was jemand anderes damit anfängt.
Also den Grundgedanken finde ich sehr gut.
Deswegen hat es mich auch riesig gefreut, dass ihr mich eingeladen habt jetzt für den Podcast.
Dankeschön. Sehr schön. Das freut uns.
Gut. Ja, wenn wir dann keine Fragen mehr haben, dann muss ich ja noch nicht mal sagen, wir sind über die Zeit.
Sind wir nämlich schon, falls wir uns überhaupt an irgendeine Zeit halten würden.
Aber das finde ich ganz interessant, dass man immer so bei, ich sage mal, 45 bis 50 Minuten rauskommt.
Und dann ist so das Gefühl da, boah, das war erstmal bis jetzt ein gutes Gespräch.
Wir könnten zwar weiterreden, aber das wäre dann nur noch 80, 20.
Also 80 Prozent haben wir schon erreicht oder 90.
Und das wäre jetzt nur noch so etwas drauf, um irgendwie Zeiten zu füllen.
Rolf, dann danke ich dir. Bin mal gespannt, wann wir uns mal wiedersehen, wann wir irgendwas irgendwann mal irgendwie zusammen machen.
Mal gucken.
Ja, ich glaube, da sind eine Menge Leute gespannt drauf.
Also ich glaube, eine Menge Leute haben jetzt wirklich bald keinen Bock mehr darauf, nur Zoom und Videokonferenzen zu haben.
Also da sehne ich mich sehr danach, muss ich sagen.
Ja, auf jeden Fall.
Also ich habe das in meiner Jahresanfangs-Mail geschrieben.
Ich glaube, dass viele Organisationen und Menschen am Rande der Belastungsfähigkeit sind.
Also es funktioniert jetzt so, wir kriegen das hin.
Wir haben die Zooms, wir haben unsere Sitzungen, wir machen unsere Arbeit.
Aber es fehlt so viel und es geht auch so viel kaputt.
Und wahrscheinlich reicht es bei manchen Organisationen, um vielleicht so sie zur Explosion zu bringen oder so.
Also ich glaube, dass vieles gerade so am Laufen gehalten wird.
Und das führt jetzt vielleicht zu weit, wenn wir das noch weiter besprechen.
Rolf, vielen, vielen Dank.
Und ich würde sagen, dann bis zum nächsten Mal.
Das war die Februar-Folge unseres Podcasts DEF OBS.
Auf die Ruhe und ins Hören.
Danke euch beiden auch.
Vielen Dank, Rolf, dass du da warst.
Vielen Dank allen fürs Zuhören.
Bis zum nächsten Mal.
Servus.
Bis dann.
Ciao.
Ciao.

Klicken Sie auf den unteren Button, um den Inhalt von podcasters.spotify.com zu laden.

Inhalt laden

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

Klicken Sie auf den unteren Button, um den Inhalt von podcasters.spotify.com zu laden.

Inhalt laden

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.