Autonome Teams werden oft als der heilige Gral der Softwareentwicklung angesehen. Sie versprechen mehr Produktivität, bessere Ergebnisse und zufriedenere Mitarbeitende. Doch Autonomie bringt Herausforderungen mit sich: Sie erfordert Vertrauen, die Fähigkeit, Verantwortung zu delegieren, und Teams, die bereit sind, diese Verantwortung zu tragen. Außerdem können zu viel Autonomie und fehlende Leitplanken zu Chaos und Kontrollverlust führen. Dieser Vortrag beleuchtet die psychologischen, organisatorischen und architektonischen Aspekte von Autonomie und zeigt, warum sie in der Praxis oft schwerer zu erreichen ist, als es scheint.

2025-01-17 Thumbnail

PeerTube Video - no Big Tech!

YouTube Video

Audio als Podcast

MP3 Download
Infos und Feeds zum Audio als Podcast

Hinweis: Die nachfolgenden Texte wurden mit KI erstellt und können somit Fehler enthalten.

Folge 247 - Autonome Teams - Wollen wir das wirklich?

Zusammenfassung

Autonomie vs. Kontrolle

Autonome Teams arbeiten unabhängig und treffen eigene Entscheidungen, was die Notwendigkeit von Koordination und Kommunikation reduziert. Dies kann zu höherer Zufriedenheit und besseren Ergebnissen führen. Allerdings ist vollständige Autonomie illusorisch, denn es gibt immer externe Abhängigkeiten und Entscheidungen, die nicht allein im Team getroffen werden können. Eine adäquate Architektur ist entscheidend, um Autonomie zu fördern – sie minimiert Abhängigkeiten und ermöglicht es Teams, ihre Ziele selbst zu setzen.

Architektur und Autonomie

Ein gut strukturiertes System isoliert Änderungen in einem Modul. Microservices ermöglichen darüber hinaus unabhängige Deployments sowie technologische Entscheidungen. Viele Organisationen streben nach mehr Autonomie für ihre Entwicklungsteams, doch häufig stehen sie vor Herausforderungen, die durch Druck und Kontrollbedürfnisse verursacht werden. Die Balance zwischen Vertrauen in die Teams und dem Drang, Kontrolle auszuüben, ist wichtig.

Psychologische Aspekte

Das Vertrauen in die Fähigkeiten von Teams und die Akzeptanz, dass nicht alles kontrollierbar ist, spielt eine zentrale Rolle. Der Wunsch nach Kontrolle führt oft zu exzessiven Planungen und restriktiven Architekturentscheidungen. Eine Kultur der Offenheit und des Vertrauens könnte die Autonomie der Teams erhöhen und die Zusammenarbeit verbessern.

Kontinuierliche Verbesserung und Standards

Die Diskussion über verpflichtende Code-Analyse und Metriken zeigt, wie Metriken helfeen können, aber auch entsprechend Goodhart’s Law manipuliert werden, wenn sie als Ziele formuliert werden. Selbstverantwortung der Teams sollte gefördert werden, um echte Qualität und Autonomie zu erreichen. Dabei müssen Standards eingesetzt werden aber so, dass sie die Teams nicht unnötig beschränken.

Key Takeaways

  1. Autonomie ist kein Selbstzweck, sondern dient der höheren Effizienz und Zufriedenheit in Teams.
  2. Architektur spielt eine wichtige Rolle beim Ermöglichen von Autonomie in Entwicklungsteams.
  3. Vollständige Autonomie gibt es nicht – es bestehen immer externe Abhängigkeiten.
  4. Vertrauen in Teams ist wichtig für den Erfolg autonomer Arbeitsweisen.
  5. Psychologische Hemmnisse, wie der Drang nach Kontrolle, müssen überwunden werden, um Autonomie zu fördern.
  6. Standards und Metriken sollten freiwillig und nicht verpflichtend sein, um die Autonomie der Teams zu wahren.

Wichtige Fragen

  1. Warum ist Autonomie in Entwicklungsteams wichtig?
  2. Welche Rolle spielt die Architektur bei der Unterstützung von autonom aufgestellten Teams?
  3. Wie können Managementpraktiken die Autonomie der Teams beeinflussen?
  4. Wie kann man Vertrauen in Teammitglieder aufbauen, um die Selbstbestimmung zu fördern?
  5. Was sind die Vor- und Nachteile freiwilliger Standards und Metriken im Vergleich zu obligatorischen Vorgaben?
  6. Wie beeinflusst die Team-Reife die Fähigkeit zur Selbstorganisation und Autonomie?

Glossar

Vollständige Transkription

Hinweis: Dieses Transkript wurde mit KI erstellt und kann somit Fehler enthalten.

Folge 247 - Autonome Teams - Wollen wir das wirklich?

So, also autonome Teams. Wollen wir das eigentlich wirklich?

Das Konzept der Autonomie

Und der Punkt ist halt, dann würden Teams im Wesentlichen unabhängig voneinander arbeiten und sie würden halt selber Entscheidungen treffen.

Abhängigkeiten und Koordination

Ich habe immer noch bestimmte Abhängigkeiten. Es ist eben so, dass wir alle gemeinsam an einem System arbeiten und das impliziert, dass da halt irgendwie Dinge sind, die wir dann eben gemeinsam machen müssen und wo wir uns koordinieren müssen. Das ist aber so, dass Autonomie kein Ziel an sich ist. Das heißt also, ich sorge jetzt irgendwie dafür, dass wir Autonomie haben, um irgendwie ein Ziel zu erreichen, was also bedeutet, dass wir irgendwie besser werden müssen. Und da gibt es halt einen Grund, warum das besser ist, weil ich eben dann weniger Koordination zwischen den Teams habe. Und das bedeutet, ich habe eben mehr Autonomie, bedeutet weniger Koordination, bedeutet weniger Kommunikation. Das bedeutet, ich habe mehr Zeit, um tatsächlich Wert zu generieren, Software zu entwickeln, Features umzusetzen. Also habe ich am Ende wahrscheinlich irgendwie bessere Ergebnisse, weil ich mich halt eher um das kümmern kann, worum es eben tatsächlich an der Stelle geht.

Selbstbestimmtheit der Teams

Es gibt dann noch irgendwie diese Selbstbestimmtheit, die da, glaube ich, eine Rolle spielt. Und Selbstbestimmtheit bedeutet, dass die Teams eben selber bestimmen, wie sie arbeiten wollen, was eben auch bedeutet, dass dort Entscheidungen getroffen werden, wo die meisten Informationen sind. Also da, wo eben tatsächlich die Teams arbeiten. Und das bedeutet eben, dass Teams sich selbst auch ihre Ziele setzen, selber kreativ sein können, wie sie ihre Probleme lösen.

Zufriedenheit und Ergebnisse

Und das bedeutet eben zum einen bessere Zufriedenheit im Beruf, aber auch wahrscheinlich bessere Ergebnisse. Der Fragzweierlei schreibt, werden Entscheidungen nicht nur im Team, sondern auch außerhalb vom Team gemacht, Stichwort Scope und Context. Ja, genau.

Grenzen der Autonomie

Also deswegen sage ich ja, vollständig autonome Teams kann es halt eben nicht geben.

Einfluss externer Entscheidungen

Es wird irgendwelche Dinge geben, die halt irgendwie sozusagen draußen sind, außerhalb der konkreten Teams. Und das bedeutet, dass es eben nicht die vollständig autonomen Teams gibt, genauso wie es eben nicht die vollständig autonomen Teile meines Systems gibt, sondern es wird eben immer irgendwie eine Interaktion geben.

Literaturhinweise

Es gibt das schöne Buch Accelerate. Und Accelerate sagt eben auch, dass die Diskussionen, die halt führen, sich häufig so auf Tools und Technologien beziehen im Architekturbereich. Also sollten wir halt irgendwie Microservices benutzen, sollten wir Serverless sein, sollten wir irgendwie Kubernetes verwenden. Und das Ergebnis ist halt von diesem Buch, das ist von der Nicole Fosgren, dem Jess Humble und dem Gene Kim. Basis ist dieses DevOps-Studium. Was die halt irgendwie sagen ist, naja, also das, was sie herausgefunden haben, ist, dass das die falschen Fragen sind, sondern die entscheidende Frage ist halt, oder das entscheidende Thema ist eben, die Teams dazu zu bekommen, dass sie Änderungen an ihrem Produkt oder ihrem Service machen können, ohne von anderen abzuhängen. Und das ist, glaube ich, eine ganz spannende Sache. Also Accelerate diskutiert eigentlich, dass man eben schneller Software deployen möchte und welche Vorteile das hat, sagt aber, dass hier eben tatsächlich dieses Ziel existiert. Und das ist, glaube ich, so ein ganz spannender Einblick.

Fallstudie: How Google Works

So, und es gibt dann dieses Buch über How Google Works. Und ich hatte da in der Vorbereitung für diesen Talk reingeschaut, weil ich dachte, dass das halt so ganz explizit da dran steht. Was ich aber am Ende gefunden habe, ist eigentlich, ist nur so eine Fallstudie, so ein Ding, was sie da halt irgendwie als gute Sache diskutieren. Und das ist eben, dass in einer bestimmten Situation die Aufgabe von einem Sergey Brin, also einem der Co-Founder von Google und auch eben damit einem Top-Manager von Google in der Situation war, seine Aufgabe, aus dem Weg zu gehen und eben nicht zu sagen, das ist halt meine Idee und meine Idee ist die beste, sondern zu sagen, nicht, liebes Team, ihr habt halt eine Idee, die ist wahrscheinlich immer besser, setzt die doch einfach um. Und dafür brauche ich halt irgendwie das Vertrauen in meine MitarbeiterInnen, aber ich brauche irgendwie auch das Selbstvertrauen, dass man irgendwie sagen kann, okay, ihr kriegt es halt hin, einen besseren Weg zu identifizieren.

Vertrauen in Mitarbeiter

Das bedeutet, abstrakt gesprochen, wenn man sich das logisch vorstellt, ist eben ein autonomes Team besser. Und es gibt eben, wie man jetzt bei Accelerate sieht oder bei Google sieht, eben auch andere Hinweise in der Literatur darauf, dass das eigentlich eine gute Idee ist. So und wir haben jetzt das Problem, es geht ja um Architektur bis zu einem gewissen Maße, dass Architektur tatsächlich Autonomie begrenzt. Also Lisa hat hier so einen schönen Big Ball of Mud geschrieben, also gezeichnet, ein großes, unstrukturiertes System.

Domänengetriebenes Design

Und aus Big Ball of Mud, so sagt Domain Driven Design, kommt so ein Partnership raus. So ein Partnership ist ja etwas, was wir naiv vielleicht irgendwie positiv sehen und der Eric Evans, der dieses Domain Driven Design Ding irgendwann mal illustriert hat, hat da so ein Dreibeinrennen als Illustration gewählt. Ich habe hier so ein Bild von, weiß ich nicht, das sind irgendwelche amerikanischen Soldaten, glaube ich, die hat so ein Dreibeinrennen machen und da bindet man sich eben zwei Beine zusammen und versucht zu rennen. Und es geht eben schlechter, weil man sich halt gegenseitig behindert. Und das ist eben gemeint mit diesem Partnership beziehungsweise mit den starken Abhängigkeiten, die halt aus Big Ball of Mud rauskommen.

Architektur und Autonomie

Das heißt also, ein Ziel für Architektur ist eben tatsächlich Autonomie. Und wenn wir so ein Big Ball of Mud haben, dann haben wir eben die Situation, dass alles von allem abhängt. Jede Änderung kann eben potenziell jeden Teil des Systems irgendwie beeinflussen. Und das kann dann zu dieser Partnership führen. Und dann haben wir halt eben an der Stelle ein Problem, also weil wir halt eben nicht mehr produktiv arbeiten können. Ich glaube tatsächlich, dass diese Partnership das sehr gut illustriert letztendlich. Und da, weil wir ein gut strukturiertes System haben, dann haben wir weniger Einfluss von Änderungen. Das heißt also, wenn ich jetzt eine gute Architektur, eine vernünftige Architektur habe, dann ist das eigentlich eine Voraussetzung eben für Autonomie. Und bei Microservices ist es jetzt so, wenn ich eine vernünftige Architektur habe, eine vernünftige Aufteilung, dann bedeutet das, dass eine Änderung nur einen Teil des Systems beeinflusst. Bei Microservices kann ich jetzt die jeweiligen Teile auch noch unabhängig voneinander deployen. Und ich kann dort auch verschiedene Technologien benutzen.

Technologische Flexibilität

Das heißt, ich habe sogar noch mehr Potenzial für Autonomie. Also es ist nicht nur so, dass ich fachliche Änderungen autonom durchführen kann, sondern ich kann auch unabhängig voneinander deployen und ich kann sogar Technologieentscheidungen unabhängig treffen. Und das ist eben dann noch mehr Autonomie. Und das ist tatsächlich ein wichtiger Grund. Also ich habe das Gefühl, viele von den Leuten, die halt irgendwie sagen, hey, hilf uns doch bei irgendwie Architekturthemen, reden deswegen mit mir, weil sie eben mehr Autonomie haben wollen. Der Alexander Herold schreibt, ob autonome Teams funktionieren, hängt für mich auch von den Rahmenbedingungen ab, zum Beispiel was man eigentlich baut. Was ja ein bisschen das ist, was ich hier versuche zu sagen. Also es ist eben so, passt auch glücklich zu der nächsten Folie, die Architektur beeinflusst die Autonomie. Architektur wird auch beeinflusst von dem, was Alexander sagt, was wir so fachlich bauen. Wir haben bestimmte fachliche Abhängigkeiten vielleicht und das beeinflusst die Autonomie. Aber wenn wir Autonomie haben, dann haben wir weniger Kommunikation, mehr Produktivität, mehr Selbstbestimmtheit. Und wir können jetzt irgendwie auch hinweisen auf Google oder Accelerate und können halt sagen, guck mal, die machen das eben auch so. Und das führt irgendwie zu der Frage, warum zum Teufel ist irgendwie Autonomie noch ein Thema? Also ich gebe hier gerade einen Talk und wenn das halt irgendwie alles klar und alles toll wäre, dann könnte man halt sagen, ich muss den Talk nicht geben. Aber offensichtlich muss ich das oder tue das und Leute hören mir zu. Von daher ist das halt glaube ich ein valider Punkt. Und das ist irgendwie komisch, weil die Vorteile sind ja eigentlich offensichtlich. Also das ist jetzt nichts Revolutionäres, was ich erzählt habe. Und ich will die auch nicht weiter erklären. Also man kann jetzt irgendwie noch länger darüber reden, dass wir halt Autonomie wollen, wie wir da irgendwie hinkommen. Und wichtig für die weitere Präsentation ist, wir suchen also jetzt eine Erklärung, warum wir immer noch nicht da sind bezüglich Autonomie, wo wir eigentlich sein wollen. Also wir haben immer noch viele Teams, die eben nicht vollständig autonom sind. Und das bedeutet, wir haben da immer noch irgendwie Herausforderungen. Und wenn wir diese Erklärung haben, dann können wir halt überhaupt erst mal versuchen, Autonomie zu erreichen. Und ich habe irgendwann schon mal eine Episode gemacht über Aircrash Investigations. Und Aircrash Investigations, also dass ich eben Flugunfälle untersuche, finde ich ist ein schönes Vorbild. Weil die gucken sich halt alle möglichen Gründe an, weswegen etwas schiefgegangen sein kann. Und das sind üblicherweise mehr als einer. Das heißt nicht, also irgendwas ist an dem Flugzeug nicht in Ordnung. Die Crew hat Entscheidungen getroffen, die halt so nicht in Ordnung sind und so weiter und so weiter. Und viele von den Problemen sind dann irgendwie so menschliche Probleme. Da gibt es eine Episode, die halt sagt, es gibt eben so Kommunikationsprobleme. Die Menschen sitzen halt im Cockpit, sagen aber nicht, was ihre Schwierigkeiten sind. Und das Ziel von so einer Aircrash Investigation ist eben dafür zu sorgen, dass so etwas nie wieder passiert. Was zum Beispiel auch bedeutet, dass dann das Training geändert wird. Also dass man dann irgendwie sagt, okay, ihr müsst irgendwie lernen, wie ihr anders arbeitet. Und das wird dann genutzt, um Fehler abzustellen. Und ich hatte diese Episode gemacht zum Thema Crew Resource Management. Crew Resource Management ist eben ein systematischer Ansatz, um dafür zu sorgen, dass die Zusammenarbeit in der Crew besser funktioniert. Und das ist eben deswegen so oder deswegen ein Thema, weil eben viele von den Flugunfällen genau darauf zurückzuführen sind. Und das ist ein Ergebnis davon, dass man irgendwie fragt, was ist denn nun tatsächlich der Grund? Und das will ich hier tun. Also warum funktioniert denn Autonomie nicht? Und da muss es vielleicht so zwangsläufige Gründe geben. Und ich glaube, ein Grund ist vielleicht Management. Also ich habe hier irgendwie eine Person, die managt das jetzt und sagt, also das Team ist irgendwie erfolgreich. Und da ist aber dann die Frage, okay, wie arbeiten die eigentlich? Und da könnte man jetzt irgendwie sagen, naja, das ist halt eigentlich egal. Aber weil sie sind ja erfolgreich. Aber wenn ich jetzt eine Situation habe, wo sie nicht mehr erfolgreich sind, dann möchte ich vielleicht wissen, was vorher der Erfolgsfaktor war, damit ich das irgendwie wiederherstellen kann. Und ich kann vielleicht dadurch auch irgendwie optimieren.

Faktoren, die Autonomie beeinflussen

Das führt dazu, dass ich irgendwie so den Drang habe, wahrscheinlich irgendwie zu sagen, okay, das ist eine Blackbox, die ist vielleicht erfolgreich. Aber ich weiß halt eben nicht, was sie tun.

Managementdrang zur Kontrolle

Und das führt irgendwie zu der Frage, was ist jetzt eigentlich meine Rolle? Also was mache ich jetzt als Manager? Ich bin ja irgendwie für den Erfolg verantwortlich. Und das ist das, was, glaube ich, auch in diesem Google-Text drin steht. Da muss man jetzt irgendwie das Selbstvertrauen haben und das Vertrauen in das Team haben, dass man sagt, okay, ich verstehe zwar nicht, was ihr macht, das ist aber offensichtlich erfolgreich. Ich gehe dann mal und das funktioniert halt schon. Und das bedeutet halt, dass ich eben davon ausgehe, dass das halt schon irgendwie richtig sein wird. Und das ist eben tatsächlich, kann ich mir vorstellen, psychologisch irgendwie auch schwierig. Und das schlägt sich manchmal an sowas wieder, das irgendwie gesagt wird nicht, also schauen wir mal bitte an, wie wir hier arbeiten. Und dann sind so Fragen, die man halt stellen kann, okay, ist das Team eigentlich erfolgreich? Und ich sehe irgendwie keine richtigen Probleme. Also meistens findet man schon Dinge, die halt irgendwie Themen sind, aber in diesem Fall eben nicht so richtige Probleme. Aber und dann kommt irgendwie vielleicht zurück, naja, gucke halt irgendwie in Detail rauf. Aber die Frage ist halt, warum? Und das ist eben tatsächlich etwas, wo, glaube ich, jetzt ein detailliertes Verständnis für eine Situation, die eigentlich okay ist, irgendwie gefordert wird. Und ich bin eigentlich eher ein Fan davon zu sagen, okay, wo sind die Schwierigkeiten und wir lösen halt die Schwierigkeiten. Und das sind hier so ein bisschen die beiden, wie soll ich sagen, die beiden kompetitiven Ansätze. Also mir, ich will das halt verstehen, ich will Dinge halt irgendwie optimieren. Aber vielleicht ist dann die Denkweise des Auftraggebers oder der Auftraggeberin eher die, dass man sagt, naja, ich möchte das halt irgendwie verstehen, damit ich mich sicherer fühle, damit ich weiß, warum die erfolgreich sind. Und damit ich das irgendwie nachvollziehen kann und irgendwie sozusagen nachts ruhig schlafen kann, weil ich eben diesen Drang habe, etwas zu verstehen. Und das bedeutet halt, dass wir letztendlich so ein Spannungsfeld haben zwischen Autonomie und Kontrolle.

Spannungsfeld zwischen Kontrolle und Autonomie

Das heißt, dass eben das Management nicht weiß oder auch nicht versteht, was die Teams eigentlich tun und das führt irgendwie zu Unsicherheit. Und damit muss man irgendwie leben können. Und das ist so ein Grund, der, glaube ich, dazu führt, dass das mit der Autonomie so ein bisschen schwierig ist, weil man dann da vielleicht doch irgendwie versucht reinzuregieren, wenn man eben nicht diese Sicherheit hat. So, The Travelling IT Consultant schreibt, das Management hat ja vielleicht häufiger das Problem, dass ein Team ganz toll arbeitet, ein anderes eher nicht.

Frage nach der Teamverantwortung

Dann ist doch der natürliche Ansatz zu gucken, wie das gute Team arbeitet. Also, ehrlich gesagt, weiß ich nicht, weil ich kann halt dann auf das Team gucken, was nicht so gut arbeitet und versuchen, das zu verstehen. Und tatsächlich ist es halt so, dass ich relativ gute Erfahrungen damit gemacht habe, zu fragen, was dann eigentlich das Problem ist und wie man besser werden kann, und zwar die Betroffenen zu fragen. Und oft kommt da halt gute Sachen bei raus, um eben dem schlechteren Team zu helfen. Kann man ja aber auch auf Peer-Ebene machen, wo man eben sagt, okay, das Team, was halt besser arbeitet, kann eben dem schlechteren Team helfen. Ich weiß halt nicht, ob ich das verstehen muss und dann halt, dass dem anderen Team sozusagen vorsetzen muss. Sondern vielleicht ist es eben ausreichend, dass die sich halt gegenseitig helfen. Also nicht, ich würde bei dem, wenn ich ein Team habe, das funktioniert und wenn es nicht funktioniert, würde ich halt anfangen, das Team anzugucken, was nicht funktioniert. Und die Probleme verstehen. Ich würde nicht versuchen, zu verstehen, warum das andere Team funktioniert, wäre mein Gefühl. Aber ja, guter Punkt, dieses Kopieren erfolgreicher Teams ist vielleicht eben ein Thema.

Vertrauensaufbau im Team

Ein anderer Punkt ist halt diese Geschichte mit Autonomie und all diese Sachen sind halt irgendwie großartig, so hier jetzt die Meinung. Aber das funktioniert halt mit den Menschen, die wir hier haben, halt nie. Und das, finde ich, ist auch wieder so ein Vertrauensthema. Also was irgendwie zu der Frage führt, okay, wie kann man Vertrauen schaffen, was irgendwie sagt, okay, doch, es wird hier funktionieren mit den Menschen, die halt irgendwie da sind. Und das führt irgendwie zu diesem Thema, dass eben das Management Teams sozusagen vertrauen muss, das Richtige zu tun. Und sich halt irgendwie zu melden, wenn es nicht funktioniert. Also das ist die andere Komponente. Also es ist immer so, dass irgendetwas schief gehen kann. Wenn es aber schief geht und jemand einem helfen kann, muss man eben sagen, nicht, also es geht gerade schief, hilft mir bitte. Und das ist, glaube ich, auch eine wichtige Voraussetzung. Also wenn man sozusagen einfach so ein Problem produziert, dann kann niemand helfen. Und das ist, glaube ich, eben auch, dann wird das Problem eben auch nicht gelöst werden. Das heißt, Probleme dürfen nicht verschwiegen werden, sondern ich muss mich an mir hinstellen und muss sagen, hier ist halt die Herausforderung, lass uns das halt gemeinsam lösen. Hier nochmal so eine Management Perspektive. Also das Projekt hat halt irgendwie nicht so funktioniert und da sind ganz viele Sachen, die wir uns halt nicht überlegt haben. Und dann kriege ich halt, manche Organisationen fangen dann halt irgendwie an und sagen, okay, ich habe also ein Projekt, das ist schief gegangen. Lass uns für das nächste Projekt jetzt wirklich mal intensiv planen und schauen, dass wir das wirklich richtig machen. Und ich finde das halt ganz schwierig und zwar finde ich das deswegen schwierig, sieht man hier auch, weil es halt ganz viele Dinge gibt, die wir halt vorher nicht antizipiert haben können. Und ich bin mittlerweile der Meinung, wenn man halt sozusagen eine Retrospektive über ein Projekt macht, dann sind halt viele Dinge dabei, die man nicht wissen kann und das sind meistens die Dinge, die tatsächlich dann bei dem Projekt zu einem Problem führen und das Ergebnis kann nicht sein, besser zu planen. Also ich habe das im Kleinen heute tatsächlich gehabt, da gibt es halt eine Situation, da sind wir jetzt in einer etwas schwierigen Situation und ich habe heute nochmal nachgeguckt und habe festgestellt, der Auslöser für diese schwierige Situation war halt nicht vorhersagbar, das heißt also die Planung, die wir gemacht haben, war fein und wir sind jetzt in einem Problem, das wir nicht vorhersagen sehen könnten und daraus leite ich jetzt eben für das nächste Mal nicht ab, dass wir mehr planen sollten, das macht halt keinen Sinn. Und das bedeutet, dass ich glaube, dass der Grund für dieses Verhalten diese Illusion von Kontrolle ist, also der Wille etwas zu kontrollieren erklärt glaube ich eine ganze Menge von Verhalten, also zum Beispiel sowas wie exzessive Planung und solche Deadlines in einem Wasserfallmodell und so weiter und so weiter, so oder exzessive Architekturregeln, die sagen, ich sorge dafür, dass die Teams eben nicht querschlagen und komische Dinge machen und das Problem ist eben, Dinge ändern sich halt und ich würde behaupten, dass man Dinge nicht vorhersagen kann, ist eben etwas, was eigentlich im ersten IT-Projekt, wenn man ernsthaft ein Review darüber macht, halt evident sein sollte, also man sollte halt offensichtlich herausbekommen, dass offensichtlich man dort Probleme hat, die man vorher nicht absehen konnte, aber irgendwie wird halt immer noch auf Planung und sowas gesetzt und ich glaube, der Grund dafür ist eben diese Illusion von Kontrolle, also ich kontrolliere nicht wirklich, sondern ich sage, ich plane jetzt mehr, ich investiere mehr Aufwand und ich ignoriere, dass ich eben bestimmte Dinge einfach nicht betrachten kann, weil ich sie nicht kenne und das ist inherent, neue Anforderungen, Dinge, die ich über die Domänen lerne, all diese ganzen Geschichten und ich mache es eben deswegen, weil ich diese Illusion von Kontrolle immer noch haben möchte. Genau, der Travelling-IT-Konsultant schreibt, die berühmten Unknowns, genau, also wobei das halt vom ehemaligen amerikanischen Verteidigungsminister kommt, ich weiß nicht, ob ich den Begriff dann irgendwie wählen will, aber so ist es halt und hier steht noch, das Problem ist, dass Verantwortung für viele definiert wird als Kontrolle haben, genau, das ist ein guter Punkt und das, wie soll ich sagen, wenn ich Ergebnisverantwortung habe oder wenn ich ein Problem habe, wenn ein Team halt nicht liefert, dann bin ich vielleicht auch dazu verleitet, es zu kontrollieren und das ist so ein bisschen das Problem und das, was ich da empfehle, ist halt, jetzt haben wir Pause und gepitchtes Audio, ich befürchte, ich kann da nicht viel tun, ich vermute, das ist tatsächlich ein Problem von StreamYard und ich verstehe auch nicht, warum, genau, so, also meine Empfehlung wäre halt an der Stelle dieser Leap of Faith, war nur die Kleinzeit und der Leap of Faith, das ist halt so ein Sprung des Glaubens, das ist so ein englisches, englische Metapher und ich habe hier so ein Bild von Flicka genommen und Wikipedia sagt halt, das ist halt etwas, wo ich an etwas glaube, was nicht beweisbar ist, passt, glaube ich, nicht so ganz auf unsere Situation und eher das Zweite, also so ein risikoreiches Ding, was ich jetzt irgendwie tue, in Erfüllung auf ein positives Ergebnis, also und mein Hinweis wäre halt, denkt darüber nach, Menschen halt zu trauen und ja, das ist irgendwie risikoreich, also das hat was mit Loslassen und Losspringen irgendwie zu tun, deswegen finde ich diese Metapher auch gut, weil ich eben rauskomme aus dieser Illusion der Kontrolle und eben sage, okay, ich kann diese Dinge nicht kontrollieren und ich komme jetzt irgendwie eben in so Terrain, wo es halt schwierig wird und wenn ich jetzt irgendwie anfange, Menschen zu trauen, dann werden sie eben auch hoffentlich mehr Verantwortung übernehmen und sich anders benehmen, also wenn es zum Beispiel keine QA gibt, wenn man also nachher nicht sagt, da gibt es eine Testabteilung, die löst für dich irgendwie nochmal die Qualitätsprobleme, dann werden wahrscheinlich Entwickler in mehr Aufwand in Testen investieren, so zumindest die Hoffnung, weil, dass sie eben da mehr Verantwortung haben und jetzt eben nicht sagen können, ihr macht das schon, sondern die sind dann halt selber verantwortlich und das bedeutet halt, wenn ich weniger kontrolliere, kann es eben gut sein, dass die Menschen mehr Verantwortung selber übernehmen und ich habe, also wie gesagt, ich habe diesen Talk schon einmal gehalten und hatte da Feedback, das war so ein bisschen für mich nebulös, aber ich habe mich deswegen dazu veranlasst gesehen, nochmal eine Folie da irgendwie reinzupacken und das ist halt diese Geschichte mit dem, also QA ist Quality Assurance, also die Menschen, die halt irgendwie Sachen testen, solche Sachen halt tun, sehe ich gerade im Chat. Also Vertrauen, es gibt Gründe, warum ich halt Menschen nicht vertraue, also das ist durchaus etwas, was halt sein kann und dann ist es halt auch natürlich fein, den Leuten halt nicht zu vertrauen und das ist ja nicht so ein ethisches Ding, das heißt, ich spreche jetzt nicht über die Menschen, die in den Stab und sage, okay, ihr vertraut den Menschen nicht, ihr seid irgendwie böse, sondern ich sage halt eigentlich eher, überlegt mal, ob ihr denen mehr vertrauen könnt und mehr Freiheiten geben könnt, weil ich glaube, dass das Ergebnis halt positiv ist. Wenn dann jemand zurückkommt, ja, habe ich probiert und es geht nicht, dann haben wir eine andere Diskussion, also das ist dann vielleicht immer noch ein Problem, was man halt irgendwo lösen muss, kann, aber ich habe es zumindest versucht. So und an dieser Stelle noch, ja genau, so ein Hinweis, was ich halt ganz spannend finde und vielleicht auch ein Szenenwechsel. Also das ist halt diese Frage mit, sollte Code Analyse verpflichtend sein für Teams? Also wir sitzen jetzt in einem großen Gremium, das halt irgendwelche Richtlinien für ein großes Projekt auflegt und das ist die Frage, sollten wir jetzt Code Analyse für Teams verpflichtend machen? Also dazu gehört sowas wie Test Coverage oder Komplexitätsmetriken, schlechte Codepatterns, dass man die irgendwie herausfindet und halt irgendwie verbietet und ihr könnt das gerne im Chat dazu auch was schreiben, ob ihr halt sagt, ja, sollte man halt oder nein, sollte man dann irgendwie nicht. Ich habe ein bisschen so lag im Stream, das heißt, ich habe irgendwie zwischen dem, was ich jetzt hier sage und eurer Reaktion vergehen in ein paar Sekunden. Deswegen würde ich, also die Möglichkeiten, die ich typischerweise zur Auswahl gebe, sind halt ja und es gibt vordefinierte Werte, die ich halt den Leuten gebe. Also was hier nicht 80 Prozent Code Coverage, 70 Prozent oder so, das würden wir jetzt also gemeinsam festlegen oder nein und die Teams würden die Ziele halt selber definieren können, also sich selber überlegen, wie viel Code Coverage sie in den Tests haben wollen, wie viel Test also aus, wie viel Code des Gesamtcodes im Test ausgeführt werden soll und dann gibt es irgendwie nein und das kann man irgendwie abvoten. Also die YouTube sagt gerade ja in all caps. So und tatsächlich ist es halt so, dass ich das relativ typisch in Trainings halt frage und ich habe da mal irgendwie mich hingestellt und habe mal versucht eine Statistik darüber zu machen und habe irgendwie 110 Antworten irgendwie raus gesammelt und das sind irgendwie so irgendwelche Random Menschen aus dem technischen Training und das ist etwas, wo also tatsächlich TechnikerInnen sind und das ist auch relativ gut reproduzierbar. Also da gibt es jetzt nicht die krassen Ausreißer. Ich sehe jetzt irgendwie ja auch zweimal ja, einmal nein. Begründung bei einem, hier Mivo sagt Teams unterstützen, diese einzubinden, wenn sie möchten und ihnen die Möglichkeit vorstellen. Das ist aber übrigens nicht verpflichtend. Wenn ich sie unterstütze, dann bedeutet es ja nicht unbedingt, dass ich das verpflichtend mache. Und fragt Zweiler, schreibt Testen kostet Geld? Naja, also das ist irgendwie die Frage. Höhere Qualität führt zu besserer Produktivität und deswegen bringt es eigentlich Geld. Das Ergebnis, wenn man da draußen hingeht, ist, dass sieben Prozent sagen nein, man sollte das nicht verpflichtend machen. 34 Prozent sagen ja und die Ziele sollte man vorgeben. Also 80 Prozent Code Coverage oder was auch immer. Und 59 Prozent sagen, das Team sollte halt selber entscheiden über die Werte, aber wir geben es halt verpflichtend vor. Genau, der Alexander Herold schreibt auch gerade nicht, Testen kostet mehr Geld, glaube ich auch. Das ist aber gerade nicht die Diskussion. Die Diskussion ist, sollen wir das verpflichtend vorgeben. Und da gibt es Gotthards Law. Und Gotthards Law sagt, wenn irgendein Wert ein Ziel wird, dann hört es auf ein gutes Ziel zu sein. Und das kann man im Code Coverage zeigen. Also das ist eigentlich ein guter Indikator dafür, ob eben der Test gut oder schlecht ist. Also der Travelling IT Konzern schreibt gerade Code Coverage ist immer das super Beispiel. Ich kann für jedes System 100 Prozent Code Coverage erreichen, ohne auch nur einen einzigen Sinn von Tests zu schreiben. Und das ist ein bisschen der Punkt. Also eigentlich ist Code Coverage tatsächlich ein guter Indikator. Also das, was der Travelling IT Konzern sagt, ist, glaube ich, richtig. Ein guter Indikator dafür, ob die Tests gut oder schlecht sind. Aber eben nur ein Indikator und es gibt mehrere. Und ich kann den halt sozusagen auch betrügen. Und das ist ein bisschen der Punkt hier. Eigentlich ist es so, wenn ich eine hohe Code Coverage habe, teste ich viel von dem Code. Und die Tests sind wahrscheinlich besser, weil eben mehr Code ausgeführt wird. Und ich habe dann halt mehr Fehler, die ich da finden kann. Und das führt jetzt, das ist eigentlich auch der Grund, warum das überhaupt interessant ist. Ich kann mir jetzt also angucken, wie hoch ist die Code Coverage? Oh, die ist niedrig. Wo ist sie niedrig? Vielleicht sollten wir da mehr Tests machen. Und darüber komme ich halt in einen Feedback Zyklus, der es mir erlaubt, die Tests besser zu machen. Und da kommt jetzt irgendwie Guthards Law. Und Guthards Law sagt, wenn ich jetzt sage, Test Coverage ist ein Ziel, dann werden die Metriken manipuliert. Das heißt, ich fokussiere mich auf die trivialen Teile des Codes. Ich überprüfe die Ergebnisse nicht. Ich teste ja nur auf Code Coverage. Das heißt, ich gucke, ob der Code ausgeführt worden ist. Ich gucke aber nicht, ob ich die Ergebnisse tatsächlich überprüfe. Und dann habe ich eine Addition. Und die Addition ergibt 2 plus 2 ist 5. Und dann sage ich, ich checke das Ergebnis nicht. Und ich habe 2 getestet, aber der Test nützt halt nichts. Oder ich habe zum Beispiel Tests, die sagen, es wird eben auch nur getestet, ob es keine Exception gibt und so weiter. Und das führt jetzt dazu, dass eben wenn ich Test Coverage angebe als ein Ziel, dass sich erhöht. Aber die Tests werden nicht wirklich mehr Probleme herausfinden, weil die Metrik eben letztendlich manipuliert wird. Und das bedeutet halt, dass jetzt die Test Coverage nicht mehr eine gute Metrik für die Qualität der Tests ist, was sie vorher war, bevor ich sie als Ziel ausgegeben habe. So und das führt jetzt irgendwie zu folgenden Problemen. Also ich kann jetzt sagen, ich gebe vordefinierte Ziele raus, dann wird mich Guthards Law erwischen. Ich sage, hat 80 Prozent Code Coverage. Ihr dürft keine Criticals haben. Also nicht so Code Patterns, die eigentlich kritisch sind, die man also vermeiden sollte. Sondern wenn ihr halt irgendwie anfangen, wenn wir sagen, okay, wir sorgen dafür, dass eben diese Metriken okay sind. Aber sie werden eben diese Metriken betrügen. Wenn wir sagen, dass das Team die Ziele selber stellt, dann haben wir etwas weniger das Problem. Aber es ist immer noch so, dass wir Standards etablieren. Und eigentlich haben wir erst bei Nein echte Autonomie. Also das, was wir hier nicht tun, ist, dass wir meiner Ansicht nach ohne echten Grund eine Entscheidung an uns ziehen. Wir sagen nicht mehr dem Team, ihr dürft es halt selber entscheiden. Das wäre Nein. Sondern wir sagen, ihr müsst. Und das bedeutet, dass ich die Autonomie tatsächlich beschneide. Und dazu muss man jetzt etwas sagen. Also die Diskussion ist nicht, ob Code Analyse großartig ist. Ich glaube, Code Analyse ist toll. Aber ich persönlich vote da halt konstant mit Nein. Weil ich möchte nicht, dass sie verpflichtend ist. Das ist aber was anderes. Ich will, dass die Teams selber entscheiden. Und ich vertraue den Teams das Richtige zu tun. Das würde jetzt bedeuten, dass ich mich hinstelle und sage, ich habe hier irgendeinen Mechanismus. Also zum Beispiel Testing. Und mit Testing kann ich mit Code Coverage bewerten. Schaut euch das doch an und schaut mal, ob euch das hilft. Dann können die Teams sagen, ja machen wir. Und das ist super. Dann war ich auch überzeugt. Oder die sagen halt Nein. Und dann will ich nicht loslaufen und schauen, ob sie es wirklich umgesetzt haben. Und ja, ich kann den Weg, um Code Analyse zu machen, gut ausbauen und es einfach machen. Ich kann zum Beispiel sagen, da gibt es eine Sona Instanz, die könnt ihr einfach benutzen. Ich gebe euch Hilfe dabei. Das ist alles fein. Aber das ist ja nicht erzwingen. Also dieses Mandatory, beziehungsweise, dass sie verpflichtend sind, das ist eigentlich das Problem. Und was ich hier spannend finde, ist, dass meine Meinung von der Mehrheitsmeinung deutlich divergiert. Und das eine, was ich spannend finde, ist, das ist eine Entscheidung, die TechnikerInnen treffen. Und das ist die selbe Geschichte, die ich vorhin beim Management diskutiert habe. Das ist auch etwas, wo ich die Autonomie von Teams beschneide, wenn ich Ja sage. Und ich weiß eigentlich gar nicht so genau, warum. Ich glaube ganz ernsthaft, dass es das nicht wert ist. Da ist jetzt eine Diskussion im Chat, die etwas sagt über Bausteine, glaube ich. Also Tests von draußen, von Schnittstellen, das ist etwas anderes. Hier geht es eben tatsächlich um so etwas wie Unitests, die halt reingucken und der hat den Test, intern testen. Ich habe irgendwie diese Visualisierung im Kopf. Genau, The Travelling IT Consultant schreibt eine Ausnahme, mache ich allerdings für Sicherheitsgeschichten, da muss man schon oft hart checken. Das ist eine Sache, die man dann diskutieren kann, die ist hier auch in der Diskussion oft drin, dass man dann sagt, aber es gibt bestimmte Sachen, die halt verpflichtend sind, ausgeschoben von Regularien, dann ist das halt so. Und genau, Tutoritt schreibt, egal, wer die Ziele gibt, es kommt immer auf Vertrauen zurück.

Bedeutung von Mentoring

Ich finde, dass PR mindestens einen Reviewer haben sollte. Man wird spätestens hier sprechen, wenn der PR die Code Coverage tricksen will. Es ist ein guter Punkt. Ich habe mir auch angewöhnt, bei vielen Sachen einen Reviewer zu holen. Nicht deswegen, weil ich mir selber nicht traue, sondern weil es die Qualität erhöht und es besser macht. Aber das ist etwas anderes. Ich sage ja auch nicht, dass Code Coverage eine schlechte Idee ist. Ich sage auch nicht, dass Reviews eine schlechte Idee sind. Ich sage halt, wenn ich Dinge verpflichtend mache, habe ich eigentlich ein Problem und ich weiß nicht, warum ich das tun sollte. Eigentlich sollte es überzeugend sein und wenn es nicht überzeugend ist, dann gibt es vielleicht Gründe, warum es nicht überzeugend ist und dann ist es vielleicht in dem spezifischen Fall eine schlechte Idee. Ich sollte also den Teams sagen, das ist vielleicht eine gute Idee, aber ich sollte es nicht erzwingen. Ich habe hier eine Entscheidung. Ich mache Metriken verpflichtend. Ich glaube, da gibt es zwei Dinge, auf die das einzahlen kann. Das ist einmal diese Geschichte mit der Softwarequalität. Ich kann jetzt versuchen, darüber tatsächlich eine bessere Softwarequalität zu erzwingen. Wir haben gerade eben gesehen, dass Gotthard Slaughter vielleicht ein Problem ist und dass es eben doch keine bessere Softwarequalität gibt. Aber ich habe noch ein zweites Ding, worum es geht und das ist dieser Effekt auf die Autonomie. Also wenn ich mich jetzt hinstelle und sage oder wir uns hinstellen als zentrale Architekturorganisation und sagen, wir entscheiden das, dann killen wir die Autonomie. Ist es das wert? Das ist die Frage und ich glaube, da muss man diese beiden Sachen abwägen. Wie groß ist der Effekt auf die Softwarequalität? Weiß ich nicht genau. Gotthard Slaughter habe ich im Hinterkopf. Kann sein und das habe ich selber erlebt, dass es tatsächlich nach hinten losgeht und die Tests eben nicht besser werden und die Metriken tatsächlich beschummelt werden. Dann habe ich hier bei der Softwarequalität keinen wirklichen Effekt und bei der Autonomie habe ich auf jeden Fall negativen Effekt, weil ich die Entscheidung an mich ziehe. Genau, Marius schreibt, es ist immer der gleiche Zwiespalt, in welchem Maß vertrauen wir dem Team und in welchem Maß wird durch Regeln gewisse Qualitätsvergleiche versucht sicherzustellen. Das ist eine politische Frage und natürlich unabhängig. Die Frage gibt es so oder ähnlich in vielen Branchen. Ja, aber ich kann nur noch mal sagen, das ist ein bisschen das, was ich hier auch versuche zu sagen. Ich bin mir sehr unsicher, ob man die Qualität schafft. Das ist auch die nächste Geschichte. Was ist denn, wenn die Qualität nicht stimmt? Natürlich ist es so, dass das Team für die Qualität verantwortlich ist. Das ist nicht der Punkt, den ich hier versuche zu machen. Ich werde also ein Team für die Qualität, die es liefert, verantwortlich machen. So oder so, weil das ist eben ein Element der Leistung, die sie bringen. Aber ich werde ihnen die Möglichkeit geben, irgendwelche Techniken zu benutzen, die sie halt wollen. Es gibt andere Möglichkeiten. Es gibt zum Beispiel Mob, Ensemble oder Pair Programming, wo sowieso zwei Leute jederzeit auf den Code gucken. Das kann eben die Qualität verbessern. Das war ja auch gerade eben die Aussage. Ein Pull Request, wo noch mal jemand drauf guckt, das passt da irgendwie auch rein. Das ist eben etwas, wo ich dann sicherstellen kann, dass vernünftige Qualität da ist und vernünftige Tests da sind. Es wäre also eine alternative Maßnahme. Code Reviews sind ja auch drin. Das heißt, ein Team kann sagen, wir arbeiten hier ohne Metriken, dafür mit Mob Programming, wo mehrere Menschen vor dem Rechner sitzen oder Pair Programming oder wir arbeiten mit Code Reviews und sie haben eine vernünftige Qualität erreicht. Das ist genau das, was sie autonom entscheiden können. Von der Reife des Teams abschreibt Alexander Herold, ob sie gut autonom arbeiten können. Das ist das, was ich mit diesem Leap of Faith meinte. Ich bin nicht sicher, was passiert, wenn man einem Team, das scheinbar nicht selber gut arbeiten will, kann. Wenn man dem jetzt sagt, machen wir trotzdem. Wir geben euch die Freiheiten, was dann passiert. Traveling IT Consultant schreibt, Reife des Teams, aber sicher auch Business Domain beim Kernkraftwerk oder in einer Banksoftware will ich auch als Privatwensch mehr Kontrolle sehen, als zum Beispiel bei einer Wetterstation. Da bin ich mir nicht sicher. Genau genommen will ich mehr Qualität sehen. Wenn wir Unit Tests machen und Auxome Programming, also alle Menschen sitzen vor einem Rechner und arbeiten gemeinsam daran, bin ich mir nicht sicher, ob die Qualität tatsächlich schlichter ist. Ehrlich gesagt, kann ich mir sehr gut vorstellen, dass sie sogar besser ist. Das ist das, was ich sagen will. Es geht hier nur um eine Technik. Qualität ist ein anderes Thema. Da sind meine Ergebnisse. Auch technische Menschen scheinen Kontrolle über Autonomie in Wirklichkeit vorzuziehen. Ich weiß nicht, warum. Ist das ein Mangel an Vertrauen? Ist das auch so etwas wie eine gute Idee? Ich muss es auch durchdrücken. Keine Ahnung. Aber die Evidenz ist schon da. Es ist schon so, dass die meisten sagen, das will ich verpflichtend machen. Vielleicht ist das mit dieser guten Idee und dem Verpflichtendmachen ein Missverständnis. Keine Ahnung. Ein anderes Beispiel ist die Geschichte mit dem Technologie-Stack. Wir sollten den Technologie-Stack standardisieren. Gerade in einem Microservices-Umfeld kann man sagen, jeder kann die Technologie benutzen, die er oder sie benutzen will. Das ist frei. Das ist eine Maßnahme, die ich im Prinzip ergreifen könnte. Da ist wieder die Frage, ob ich das mache. Lasse ich den Teams diese Autonomie? Da gibt es Gründe dafür. Das Team kann entscheiden, was das richtige Werkzeug ist. Das Gegenargument ist meistens, dann habe ich einen Chaos und Anarchie. Ich habe da eine eigene Idee. Das ist die Convergence-Hypothese. Die Konvergenz-Hypothese basiert auf der Überzeugung, dass ein Team eine Menge Vorteile hat, wenn es dieselbe Technologie benutzt wie alle anderen. Fragzweiler schreibt, dass das gerade ein Beispiel ist, weil das als Kritik an Microservices benutzt wird. Genau genommen wird als Kritik an Microservices benutzt, dass es in Anarchie endet. Dem will ich diese Convergenz-Hypothese entgegenstellen, die ich auch tatsächlich gesehen habe. Das ist der Punkt, wenn alle dieselbe Technologie benutzen. Ich habe irgendwie fünf Teams um mich herum. Die machen alle Java-Microservices. Wenn ich jetzt auch Java-Microservices habe, dann habe ich Vorteile. Ich habe Wissen um mich herum. Ich habe eine Infrastruktur, die damit umgeht. Das heißt, ich werde eigentlich ein Bias haben, dieselbe Technologie zu benutzen. Ich habe einen Java-Hintergrund, aber wenn ich jetzt in eine Umgebung komme, wo ganz viele Leute Node machen, dann ist es vielleicht so, dass es eine gute Idee ist, für mich auch Node zu machen, weil es gibt eben eine Infrastruktur, außer es gibt jetzt irgendwie einen signifikanten Nachteil. Keine Ahnung, es ist halt viel zu langsam. Machine Learning mit Python höre ich häufig, dass das eine Sache ist, die dort besonders gut ist. Das heißt, an bestimmten Stellen habe ich vielleicht mit bestimmten Sprachen und Infrastrukturen einen Nachteil. Dann ist es vielleicht sinnvoll, eine andere Technologie zu benutzen. Der einzige Grund, wo ich jetzt ein Chaos und Anarchie ende, ist, wenn die tatsächlich nicht verantwortungsvoll handeln. Aber dann habe ich ein anderes Problem. Was ich versuche zu sagen ist, wenn alle um mich herum eine bestimmte Technologie benutzen, Java, JavaScript, habe ich eine Inzentivierung dafür, genau diese Technologie auch zu benutzen. Ich werde mir überlegen, ob ich wirklich etwas anderes mache. Ich werde also eher nicht in Chaos und Anarchie enden, es sei denn, ich bin verantwortungslos. Das führt dann dazu, dass einige Teams in einem Kontext, war das zumindest die angenommene Erklärung dafür, dass eine Technologie benutzt worden ist, dass man sagt, das will ich im Lebenslauf stehen haben. Natürlich werden auch Projekte ab irgendwann unwartbar. Das heißt, eine bestimmte Menge an Guidance braucht man schon.

Vertrauen in Teamentscheidungen

Ich plädiere nicht unbedingt dafür, blind zu sagen, macht halt, was ihr wollt. Aber es ist eben die Frage, ob das nicht übertrieben wird. Die Frage ist, warum haben wir wenig autonome Teams? Ich glaube, dass ein Grund dafür ist, dass eben solche Sachen teilweise übertrieben oft eingeschränkt werden. Marius schreibt, Standardisierung an sich ja, aber wenn Infrastrukturanforderungen von Produkt zu Produkt unterschiedlich sind, braucht man vielleicht auch mehrere wählbare Stacks. Genau, das ist ja das, was ich hier versuche zu sagen. Oder eben eine Autonomie, die irgendwie sagt, okay, die Teams werden sich schon für die richtige Technologie entscheiden. Da ist wieder so ein Leap of Faith. Das bedeutet, ich würde behaupten, wenn ich leicht Menschen vertraue, werde ich sie eher autonom arbeiten lassen. Wenn nicht, werde ich sie eher kontrollieren. Das kann mit guter oder schlechter Erfahrung zusammenhängen. Wie gesagt, ich will das gar nicht bewerten. Ich versuche ja Erklärungen zu finden. Dann ist das vielleicht etwas, woran man arbeiten kann. Man kann die Technologiestacks auf eine Auswahl begrenzen, ist aber immer noch dasselbe Thema. Warum gebe ich nicht vollständige Autonomie? Ich vertraue halt den Teams, dass es eben nicht im Chaos endet. Wenn man sagt, ich kann diesen Teams ja nicht vertrauen, dann weiß ich halt, warum man da keine autonome Entscheidung fällt. Ich habe eine ganze Episode gemacht zu diesem Mikro- und Makroarchitektur-Thema. Da diskutiere ich das im Detail. Wie schon gesagt, ich brauche Standards. Autonomie bedeutet weniger Kommunikation. Kommunikation ist Architektur. Wenn ich ein Kommunikationsproblem habe, dann habe ich am Ende auch ein Architekturproblem, was Conway eben auch beschrieben hat. Er hat eben gesagt, wenn ich ein großes Projekt habe, wo Kommunikation schwierig wird und Kommunikation zusammenbricht, dann habe ich auch so ein Architekturproblem.

Standards vs. Autonomie

Das bedeutet, ich muss so eine konzeptionelle Integrität haben. Ich muss also dafür sorgen, dass ich zumindest ein paar Sachen eindeutig hinbekomme und dass das eben funktioniert. Also muss ich Leitplanken einziehen und dafür sorgen, dass die Kommunikation, zumindest einige Dinge, funktionieren. Das wird irgendwie Autonomie beschränken. Die Aussage ist nicht, lasst die Teams einfach autonom loslegen, sondern die Frage und das Kunststück ist herauszufinden, wie viele Standards und Einschränkungen von Autonomie brauche ich denn tatsächlich. Dann gibt es noch diese Geschichte mit Autonomie gegen Menschen, die 9 to 5 einfach irgendwas runterarbeiten wollen. Das sind Menschen, die vielleicht gesagt bekommen wollen, was sie zu tun haben. Wenn ich denen Autonomie gebe, bedeutet das auch, dass ich ihnen Verantwortung übertrage, was aber schwierig ist, weil sie dann eben Verantwortung haben und dann wird es irgendwie komplizierter. Die können immer noch einen guten Job machen, um bestimmte Dinge einfach durchzuexerzieren und durchzuimplementieren und durchzuarbeiten. Da ist noch ein wichtiger Punkt. Die Menschen, die wir beschäftigen als MitarbeiterInnen, haben ja auch darüber hinaus ein Leben und da treffen sie auch irgendwelche Entscheidungen. Ich hatte mal einen Artikel gelesen, da stand drin, die kaufen für viele Jahresgehälter ein Haus. Das ist eine massive Entscheidung, die sie treffen, die sie selber stark beeinflusst. Das heißt, es gibt einen Bereich außerhalb des Geschäftslebens, wo sie vielleicht große Entscheidungen treffen. Da könnte ich auf die Idee kommen zu sagen, prinzipiell könnt ihr das. Ihr macht es erfolgreich in anderen Kontexten. Ich gebe euch mehr Autonomie. Vielleicht hilft das und da sind wir wieder bei diesem Leap of Faith. Nochmal im Zusammenfass. Autonomie steht in so einem Spannungsverhältnis zu Vertrauen. Vertrauen kann gestört sein aus guten Gründen. Sowas wie, dass ich akzeptieren muss, dass ich nicht alles verstehe. Diesen Drang, Dinge zu kontrollieren, den wir alle haben. Dieses Erzwingen, statt zu überzeugen. Code-Reviews, Code-Metriken können eine gute Idee sein, aber ich will sie vielleicht nicht erzwingen. Ein paar Standards brauche ich immer noch. Das schränkt die Autonomie an und manche wollen nicht erzählt werden, was sie tun sollen. Die Beispiele sind dieser Text-Tag, wo ich sagen kann, das ist etwas, was ich einschränke oder eben auch nicht. Oder Code-Analyse. Das sind Dinge, die uns als Techniker beeinflussen. Wer entscheidet was? Das ist eine technische Entscheidung. Gebe ich das den Teams oder nicht? Sage ich denen, ihr müsst Code-Analyse machen? Sage ich denen, ihr müsst Technologie-Stack benutzen? Oder gebe ich denen die Kontrolle?

Der Schlussgedanke zur Autonomie

In der Zusammenfassung. Autonomie macht Sinn. Viele Architektur-Modernisierungen gehen genau in diese Richtung. Ich glaube, dass das Hauptproblem auf einer psychologischen Ebene ist. Also die Frage, kann ich zum Beispiel Menschen vertrauen? Vertraue ich Menschen? Kann ich mit dieser Unsicherheit leben?

Empfehlungen für die Praxis

Mein Hinweis wäre, diesen Lip of Faith, also diesen Sprung des Vertrauens zu gehen. Ich will nicht in eine Abrede stellen, dass ich Standards benötige, bei Text-Tags, bei Architektur, damit alles zusammenpasst. Aber ich bin mir immer nicht so sicher. Deswegen hatte ich eben gesagt, es gibt zwei Ebenen, auf denen ich arbeite. Einmal die Autonomie und zum anderen die konkrete Entscheidung. Wenn ich Entscheidungen an mich ziehe, dann limitiere ich damit Autonomie. Ist es das wert? Das ist die Frage, die man sich stellen muss. Genau. Vielen Dank für die Aufmerksamkeit. Vielen Dank für die Fragen und die Diskussion. Und für das Feedback natürlich auch vielen Dank. Nächste Woche, wie gesagt, gibt es CodeCarter. Das ist ein System für Visualisierung von Systemen mit dem Richard Groß. Das ist einer der Menschen, die daran arbeiten. Da freue ich mich drauf. Vielleicht sehen wir uns da. Ansonsten wünsche ich ein schönes Wochenende und bis zum nächsten Mal.