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.