Der nachfolgende Text wurden mit KI erstellt und kann Fehler enthalten. Fehler gefunden? Bei GitHub editieren

Folge 318 - Wie fährst du dein Projekt zuverlässig an die Wand?

Mit Andreas Monschau Hier ein Hinweis in eigener Sache.

Software-Architektur im Stream live vor Ort.

Wir sind bei den IT-Tagen im Dezember in Frankfurt mit dabei.

Mehr Infos dazu und spezielle Rabattcodes für unsere Community findest du auf unserer Website software-architektur.tv.

Sei dabei, stell Fragen und komm auch gern auf uns zu.

Ja, hallo und herzlich willkommen nach diesem schönen Intro zu einer weiteren Folge von Software-Architektur im Stream.

Heute zu Gast ist Andreas Monschau.

Wir haben das Thema, wie fährst du dein Projekt zuverlässig an die Wand?

Und Andreas ist da Experte im Zuverlässigen.

Nein, du hast Erfahrungen gesammelt, wie man Projekte zuverlässig an die Wand fährt durch Beobachtung, oder?

Stell dich doch mal kurz vor.

Ja, genau.

Vielen Dank.

Mein Name ist Andreas.

Ich mache seit rund 25 Jahren IT in der einen oder anderen Form, habe also viele Projekte in verschiedenen Rollen wahrnehmen dürfen und bin mittlerweile, ich möchte nicht sagen, zynischer Beobachter im Software-Projektumfeld geworden.

Aber zumindest beobachte ich immer wieder Dinge, die auftreten unterschiedlich starker Ausprägungen.

Da fing ich mal an, diese ganzen Themen zu sammeln und war dann doch recht erstaunt, wie viel Wiederholung da häufig drin liegt.

Also ich finde es ja auch ganz klasse, weil ich meine, oftmals ist man ja in so einem Projekt und denkt sich, ja Mensch, also komm, das wissen wir doch, dass das so nicht klappt.

Und von daher finde ich diesen Ansatz, das tatsächlich zu sammeln, um es sichtbar zu machen, um den Elefanten, der im Raum steht, eben tatsächlich mal zu benennen.

Und das finde ich klasse.

Du hast ziemlich viel Erfolg mit deinem Vortrag, oder?

Das resoniert mit den Leuten.

Die Leute sagen, oh ja, oder?

Na gut, ich bin ja mit einem pädagogischen Auftrag unterwegs.

Wesentlich ist ja, wir sind ja alles Menschen, wir sind in unseren Software-Projekten, haben unsere ganzen Rollen, wir sind Entwickler, wir testen, wir machen Frontends, wir machen DevOps, wir managen etc.

Und im Grunde ist auch die Vorstellung, wenn eigentlich alles glatt laufen würde, dann wäre es ja irgendwie auch langweilig.

Weil Projekte sind halt manchmal chaotisch, unvorhersehbar, hinter jeder Ecke lauert irgendwie eine neue Überraschung.

Und daher gehe ich mit diesen pädagogischen Prinzipien, diesen goldenen Regeln, auf die Konferenzen, auf die Meetups und berichte darüber.

Und bin selber irgendwie relativ erstaunt, wie groß eigentlich auch der Anklang ist, den es findet.

Also wenn ich jetzt bedenke, ich habe den Talk erstmalig beim DevDay in Dresden gehalten dieses Jahr und habe den dann direkt zweimal gehalten.

Da kam bevor ich den das erste Mal gehalten habe, kam ich vor, hier, viele kündigen jetzt gerade die Seeligen im Alternativprogramm etc.

Magst du den nachher nochmal halten?

Ja klar, gerne.

Fand ich in dem Moment schon recht überraschend, aber natürlich positiv.

Hast du eigentlich das Gefühl, du sprichst ja jetzt von Softwareprojekten, dass Softwareprojekte speziell sind, dass es da leichter Überraschungen gibt?

Vielleicht weil kein Projekt wie das andere ist?

Keine Wiederholung, weil Wiederholung wäre ja kopieren.

Wiederholung wäre kopieren, ja.

Ich glaube, das kann man so pauschal jetzt nicht sagen.

Ich glaube, viele der Themen, die ich da so ein bisschen aufwerfe oder zeige, können überall, was weiß ich, Automotive oder sonstigen Bereichen, überall irgendwie auftauchen.

Aber ich glaube, gerade in der Softwareentwicklung haben sich so ein paar Dinge über die Jahre, Jahrzehnte eingeprägt, die immer und immer wieder auftauchen und man es eigentlich mittlerweile besser wissen müsste.

Meine Theorie dazu ist, dass wir einfach alles Menschen sind und gerne Sehnen in den Augen und Verderben laufen.

Das sagst du recht schön, weil das ist ja gerade auch dabei, sich so ein bisschen zu wandeln.

Wie groß ist die Rolle der Maschinen im Projekt und wie viel die des Menschen?

Aber dein Fokus ist halt tatsächlich auf den Menschen und das finde ich sehr spannend.

Wollen wir mal anfangen?

Willst du mal den ersten Punkt, was dir so aufgefallen ist, was du auf deiner Liste mitgeschrieben hast, mal einwerfen?

Ja, können wir im Grunde direkt mal mit starten.

Vielleicht vorab noch so ein bisschen die Überlegung, wo reden wir von Projekten, die irgendwie Probleme haben oder wie viele gibt es davon überhaupt?

Und ich glaube, Probleme in der einen oder anderen Art und Weise hat vermutlich jeder mal festgestellt.

Was ist überhaupt ein Problem?

Das kann ja reichen von, wir stehen kurz vorm Abgrund bis hin zu, oh mein Gott, ich habe einfach noch nicht meine Entwicklungsumgebung.

Und da gab es vor fünf, sechs Jahren eine Auswertung, das ist der sogenannte Standish Group Chaos Report, der 2020 erhoben wurde.

Und da wurden quasi global Beteiligte von IT-Projekten gefragt, hey, wie sieht es eigentlich in euren Projekten so aus?

Läuft alles gut?

Habt ihr Probleme?

Seid ihr erfolgreich?

Seid ihr nicht so erfolgreich?

Und die Zahlen waren erstmal insofern ganz interessant.

Denn im Grunde, und das ist interessant, 31 Prozent aller IT-Projekte sind erfolgreich.

Das können wir erstmal so mal sacken lassen.

31 Prozent klingt erstmal viel, aber da bleibt natürlich noch so ein bisschen was übrig.

Denn insgesamt ein Fünftel, knapp ein Fünftel, 19 Prozent laufen komplett gegen die Wand oder scheitern halt auch eben vollständig.

Und das verbrennt ja nicht nur Geld, das verbrennt Karriere.

Das ist ja unglaublich viel, was mit dranhängt.

Bleibt nochmal 50 Prozent übrig und diese Projekte sind zumindest mit irgendwelchen Arten von Problemen behaftet in unterschiedlichsten Ausprägungen.

Das fand ich mal interessant.

Gibt es da auch eine Definition von Scheitern und Erfolgreich?

Also ich erlebe immer wieder, dass viele Projekte nicht scheitern, weil man dann das Ziel umdefiniert.

Weil man dann irgendwie die Deadline nach hinten schiebt oder man tatsächlich eben auch Scope rausnimmt und solche Geschichten.

Weil oftmals ist es ja so, dass man das Scheitern vermeiden möchte und dann irgendwie versucht es, wenn es schönreden ist.

Ja, ich glaube, die Projekte, die erfolgreich sind, sind glaube ich häufig die schöngeredeten oder wenn die halt eine Scope-Änderung hinter sich haben.

Scheitern kann in dem Kontext halt wirklich sein, ja, es ist so teuer, so aufgebildet, hier müsste wirklich der Stecker gezogen werden.

Das habe ich persönlich in der Form nicht erlebt.

Zwar habe ich schon Projekte, die kurz davor standen, aber dann passierte halt das.

Ah, wir definieren das um, machen damit einen Erfolg draus.

Es mag es ja auch da draußen geben, die Projekte, die wirklich ohne Problematiken unterwegs sind, wo man am Ende sagt, boah, hier alle Ziele erreicht.

Budget nicht überschritten.

Super, wir geben jetzt dann quasi einen Wartungsmodus rein und eine Attacke.

Aber ich glaube persönlich, wo wir uns am häufigsten bewegen, das sind die Projekte, die grundsätzlich Probleme haben.

In diesem breiten Spektrum.

Jetzt, wo du es so beschreibst, fällt mir auch auf, ich glaube, die Projekte, die so glatt durchlaufen, die bemerkt man gar nicht so.

Die anderen, da wird drüber geredet, gelästert und jeder weiß es besser.

Aber die, die einfach durchlaufen, da merkt man vielleicht, ach, guck mal, da, Software hat sich was geändert, ist ja cool.

Aber man macht sich keine Gedanken, warum das ein Erfolg war.

Umgekehrt, warum es kein Erfolg war, hat man viele Lösungen, viele Antworten.

Ja, es ist auch, glaube ich, dass auch wieder sowas Menschliches an der Stelle.

Wir erinnern uns ja häufig mal gerne an die schlimmen Dinge.

Und manchmal blenden wir die positiven Dinge einfach aus.

Wir bewerten die Dinge, die vermeintlich schlecht sind oder schlecht sind, höher.

Und das ist vielleicht auch ein Phänomen, was hier nochmal zum Tragen kommt an der Stelle.

Also ich kann mich, man guckt ja manchmal auf seine Projekthistorien mit so einem gewissen, ach ja, damals, ach, das waren noch Zeiten.

Dann verklärt man manche Dinge, aber trotzdem bleiben so gerade diese unschönen Dinge.

Seien es zwischenmenschliche Episoden oder seien es irgendwelche anderen Dinge, die bleiben trotzdem irgendwo stark haften.

Dass man denkt, schön, dass wir es am Ende abgeliefert haben, aber das und das war halt doof.

Aber andererseits habe ich auch mal von jemandem gehört, dass die Projekte, die so ein bisschen unfertig sind, wo nachgebessert werden muss und so, die bleiben im Gespräch.

Da werden die externen, die Consultants, die daran gearbeitet haben, die werden immer wieder kontaktiert.

Ihr müsst noch dies und jenes machen und sonst was.

Und derjenige, der mir das erzählte, der hat halt tatsächlich gesagt, dass er out of business gegangen ist, weil sein Projekt das nicht hatte.

Das war geliefert, das war alles in Ordnung und niemand hat mehr an ihn gedacht.

Fand ich auch einen interessanten Gedankengang jetzt, wo wir drüber reden.

Das kann man ja im Prinzip noch weiterführen.

Was könnte dann auch heißen, wenn wir hier alles wirklich abliefern, fristgerecht, auch im gleichen Budget, dann ist es fertig.

Dann verdienen wir gar kein Geld mehr dran.

Dann drehen wir vielleicht ein bisschen, dass es gar nicht mehr so glatt läuft und können das noch länger melken.

Aber man weiß es ja nicht.

Das ist gerade nur so eine Idee.

Ja, könnte.

Könnte, würde keiner machen.

Ja, du hast mich ja im Prinzip schon mal gefragt nach so ersten Maßnahmen, wie man ein Projekt, sagen wir, zumindest ruinieren könnte oder wie man es auf einen guten Weg bringen kann.

Also das heißt, du kommst jetzt so quasi direkt von der aktiven Seite.

Nicht, oh, was müssen wir beachten, dass das Projekt nicht scheitert, sondern mal so richtig schön von der anderen Seite.

Hey, was kann ich jetzt machen, damit ich es an die Wand fahre?

Finde ich cool.

Ja, genau.

Also das ist mein Ansinnen.

Andersrum wäre, naja, da müsste ich ein bisschen was richtig machen.

Aber andersrum, wie gesagt.

So ist es der Profi-Ansatz.

Ja, genau.

Destruktiv statt produktiv.

Aber ich glaube, das Allererste, was man eigentlich ganz gut machen kann und darum ging auch der erste Talk, den ich so ein bisschen in dieser Thematik hatte, war es, wenn wir uns so ein Projekt vorstellen, haben wir es ja häufig, wir haben es mit Fluktuation zu tun.

Menschen kommen, Menschen gehen, Menschen gehen, Menschen werden ersetzt durch neue, da werden vakanzenfreie Positionen besetzt werden.

Und hier kann man im Prinzip schon zu Beginn ansetzen.

Das heißt, ob es jetzt Junioren sind oder Senioren, die da jetzt irgendwie besetzt werden müssen oder danach rücken, dass man dort von Anfang an schon ein, ich setze es mal unter dem Urbegriff, unerfreuliches Willkommen bereitet.

Dass man sich gar nicht vorbereitet auf diese Menschen, die da kommen.

Da kommt jemand, ach, ich muss mich um den kümmern, ach, will ich nicht, ach gut, dann mache ich es halt so ein bisschen.

Und dann kommen diese Menschen an und sind eigentlich häufig hochmotiviert, sollen ja frischen Wind reinbringen.

Und man beachtet sie gar nicht, holt sie vielleicht dann irgendwie ab beiläufig.

Ach ja, du bist jetzt also hier, wir haben eigentlich keinen Plan für dich.

Komm mal mit, wir setzen dich da hin und ein paar Tage kümmern wir uns um dich.

Diese Situation, ein neuer Mitarbeiter kommt und hört als erstes mal, ach ja, wir bestellen dir gleich mal ein Notebook, das ist dann in vier Wochen da, dass du arbeiten kannst.

Ich meine genau, das Notebook ist in vier Wochen da, aber jetzt die ganze Entwicklungsumgebung, das wird noch mal acht Wochen dauern, bis du da wirklich vollkommen arbeitsfähig bist.

Das tröpfelt dann nach und nach rein.

Aber das ist ja quasi schon wirklich dieser Onboarding-Prozess im Prinzip.

Aber wenn es aufs Zwischenmenschliche zurückgeht, dann ist zum Beispiel wirklich dieses Nicht-Beachten schon mal ganz gut.

Ja, du bist jetzt halt da, ich bin der und der, aber mehr hörst du von mir nichts mehr.

Umso besser, man muss sich auch vorstellen, diese Menschen, die neuen Projekte reinkommen, die haben ja erst mal Fragen, die wissen ja gar nicht, was sie machen sollen, die wissen nicht, wo sie anfangen sollen.

Und dann ist es auch ganz gut, wenn man einfach nicht erreichbar ist.

Ja, aber man hat doch auch im Bewerbungsprozess vorher gescreent, dass man da Leute hat, die eigenständig arbeiten werden, oder?

Ja, genau.

Sich zurechtfinden und eigenständig irgendwie die Kontakte finden und die Prozesse.

Genau.

Wieso soll man Händchen halten?

Wir sind ja alle Erwachsenen.

Wir brauchen keinen Onboarding-Plan.

Wir sind doch Profis.

Profis, natürlich hochbezahlt.

Deswegen brauchen wir da uns nicht so viel zu verausgaben.

Das heißt, wir haben also keinen echten Onboarding-Plan, vielleicht kommt ja irgendwann auch der Zeitpunkt, wo sie vielleicht produktiv werden könnten.

Und wo man ihnen Aufgaben geben soll.

Weil es gibt bestimmt irgendjemanden ganz oben, der sagt, wir haben diese teure neue Ressource.

Neue Entwickler sind Ressourcen, keine Menschen sind Ressourcen.

Ressourcen sind ja austauschbar.

Aber diese neue Ressource muss ja mit Aufgaben versorgt werden, denn sie kostet ja Geld.

Welche Aufgaben gibt man da?

Arbeit mal das ab.

Klar, du kennst dich mit der Fachlichkeit und der Technologie aus, aber guck es dir mal an.

Wir haben gerade keine Aufgaben für dich, guck dir mal ein bisschen Doku, kommen wir gleich auch noch zu.

Oder man gibt völlig unterfordernde Aufgaben.

Ja, wir müssen mal hier eine Library updaten.

Mehr haben wir diese Woche für dich nicht.

Wir vertrauen dir nicht, dass du noch mehr kannst.

Und du mach bloß keine Fehler, denn wenn du Fehler machst, werden wir dich niemals vergessen lassen.

Aber das ist dann doch für mich als den Neuen ganz praktisch, wenn ich sagen kann, okay, ihr habt nichts für mich, aber ich bin hier heute Morgen aufgetaucht, ich trinke meinen Kaffee und gehe um 17 Uhr wieder und rechne das ab.

Das ist doch klasse, oder?

Grundsätzlich ja, aber ist das förderlich für die Motivation?

Ich meine, man lernt jetzt auch damit nichts bei.

Man erhöht vielleicht seine Frustrationstoleranz oder seine Geduld.

Ich meine, Langeweile ist auch was Gutes, da stehen ja großartige Dinge draus.

Aber wenn ich mir jetzt vorstellen müsste, ich sitze acht Stunden rum, hab einen Kaffee, vielleicht keinen Rechner, weil der erst in drei, vier Wochen kommt.

Und da hast du sicher ein paar Spiele drauf.

Okay, ist dann aber wieder problematisch, wenn am Ende der ersten Woche vielleicht doch jemand aus dem Management kommt und sagt, okay, und, was haben Sie schon gemacht?

Ah, kann ich mich jetzt trauen, die anzusperzen, die mich hier onboarden sollen?

Also man kommt da, glaube ich, schon in gewisse Konflikte.

Also ich sehe hier auch gerade einen ersten Kommentar.

Da kommt ein bisschen Kritik an deinem Ansatz rüber.

Saueres, geplantes Onboarding mit Menschen, das wäre schon ganz gut.

Ja, aber das kostet ja alles so viel Zeit und Geld.

Und wer hat denn da Lust drauf?

Ernsthaft?

Onboarding?

Ja, und ich meine, das ist doch profimäßig Training on the Job, oder?

Ich meine, sonst gäbe es ja den Begriff nicht.

Ja, eben.

Also alles hat irgendwie seinen Sinn und Zweck, gerade das.

Ja, die Leute an der Kaffeemaschine kennenlernen.

Und das ist natürlich jetzt hier in der Remote-Situation dann auch spannend.

Hilft Remote eben auch, ein Projekt gegen die Wand zu fahren?

Also mit Sicherheit, wenn man Leute ignoriert oder wirklich alleine lässt oder ihnen wirklich keine sinnvollen Aufgaben gibt.

Das ist auch mal was, was ich mir auch so richtig überlege.

Das ist ja so auch der Punkt.

Man ist ja als Neuling irgendwas völlig alleine gelassen.

Vielleicht hat es viele Fragen, aber keine Antworten.

Hat dann vielleicht Ansprechpartner bedankt bekommen.

Diese Ansprechpartner sind aber nicht erreichbar.

Einfach aus purer Ignoranz bis hin zur Boshaftigkeit.

Und das ist natürlich super einfach, sich in dieser Remote-Welt zu verstecken.

Man macht halt hier sein Teams.

Ich bin beschäftigt, bin in einem Call, stellt sich da irgendwelche Termine ein, was auch immer.

Geht nicht ans Handy, ignoriert Anrufe oder Mails, werden nicht beantwortet.

Was möchte ich dagegen machen?

Wenn alle im Office sind, muss man sich unter dem Schreibtisch verstecken, wenn man nicht vom Neuling belästigt werden möchte.

Aber solche Maschinen gibt es halt virtuell selten.

Andreas, ist das nicht der natürliche Move, dass man ein Projekt verstärkt, weil eben da ein paar Leute total landunter sind und man diesen Leuten dann eben die Neuen zuweist?

Weil die sollen ja diese Person, die landunter ist, unterstützen.

Und das ist ja auch das Problem.

Es ergibt sich doch automatisch, dass man nicht die Zeit hat.

Richtig.

Es ergibt natürlich auch die Möglichkeit, deinen Neuling schon komplett von Tag eins, sobald er natürlich arbeitsfähig ist, oder sogar bevor er noch arbeitsfähig ist, einfach so viel Zeug auf den Tisch zu knallen und sagt, mach.

Frag mich in zwei Wochen, wenn du nicht weiterkommst.

Dein Notebook ist noch nicht da, aber wir haben dir mal das Wiki ausgedruckt.

Hier ist der Leitsordner.

Genau, Leitsordner, alles Mögliche.

Man kann dann entweder zu wenig Aufgaben, unterfordernde, zu viele Aufgaben für dem, was man eigentlich gerade leisten kann.

Ich meine, machen wir uns auch nichts vor.

Man ist ja nicht direkt nach einer Woche schon, selbst wenn man die Technik vor sich hat, wenn man seine Möglichkeiten hätte, in der Lage, wirklich produktiv zu arbeiten.

Nicht nach einer Woche, nach zwei, aber nicht nach einer Woche.

Aber man kann ruhig erstmal am Tisch knallen.

Ich sehe hier gerade ein Kommentar, dass das Remote wohl doch auch klappt.

Aber ich glaube, es ist etwas schwieriger, als wenn es vor Ort ist. Übrigens, wir haben ja jetzt hier ganz viele Zuschauer, und ihr habt alle den Chat unter Kontrolle.

Gebt uns Feedback, gebt uns eure eigenen Erfahrungen.

Wir sind neugierig.

Vielleicht in dem Zusammenhang noch, wenn ich diesen Talk halte, gibt es tatsächlich am Ende immer eine Menti-Umfrage.

Die erste Frage ist im Prinzip, wie viele dieser Regeln, die ich benenne.

Ich benenne meistens zehn Regeln.

Habt ihr selber schon erlebt?

Danach gibt es auf dem zweiten Slide einen Freitext, wo man seine eigenen Erfahrungen noch mal kundtun kann.

Da ist alles dabei von »Das geht dich gar nichts an« bis »Es ist so viel, das kann ich gar nicht rezitieren.« Das ist hochinteressant, woran ich selber nicht denke und was ich selber noch nie erfahren habe.

Wir hätten eigentlich so eine Bingo-Karte zum Selbstausdrucken irgendwie rausgeben können.

Ich kenne hier einen Kommentar, sehr spannend.

Nichts machen und Kaffee trinken ist nicht super, Unterforderung ist deutlich schlimmer.

Jetzt bin ich gerade am Überlegen, ob Kaffee trinken nicht so schlecht ist wie Unterforderung.

Ich kann mir da schon was vorstellen, aber ich habe nicht so richtig die Begrifflichkeit dafür im Kopf.

Ich glaube, es wird schon fast ein bisschen philosophisch an der Stelle.

Ich glaube, die Unterforderung ist dann gleichzeitig noch »Das schwingt einen.

Oh, die trauen mir ja gar nichts zu mit.« Das ist ja ein bisschen wie ein Witz.

Beim Nichtstun, die geben mir halt nichts.

Ich kann mir schon vorstellen, dass man dieses Gefühl der Unterforderung wirklich sehr befüttern kann, wenn man solche eher rührige Aufgaben übermittelt.

Das ist auf jeden Fall ein Pro-Tipp.

Hier kommt noch »Burnout vs. Boreout«.

Das ist dann die Unterforderung, wenn man sich langweilt und sagt, »Ich habe die zwei Sachen, die du mir gesagt hast, schon gemacht.

Was soll ich den Rest machen?« Spannend.

Also das Onboarding, das ist schon mal echt was, womit ich ein Projekt in die richtige Richtung steuern kann.

Genau, und von da können wir direkt schon zum nächsten Thema kommen, was auch ganz spannend zu diskutieren ist.

Was sagt man denn jemandem, der neu anfängt, häufig mit das allererstes?

Sag es mir.

Lies doch mal was Doku.

Ja, achso, Doku ist mein Thema und meine Erfahrung ist, ja, guck mal auf den Sharepoint, schau mal, ob du was findest.

Vielleicht kannst du es neu strukturieren, damit es besser lesbar ist.

Schau mal, was dir fehlt, um reinzukommen, damit wir die Doku verbessern.

Ja, das ist was ganz Tolles.

Das ist eine Win-Win-Situation, die man sich erhofft.

Zum einen, man hat den Neuling beschäftigt und gleichzeitig wird dann noch die Dokumentation geupdatet oder aktualisiert.

Aktualisieren?

Wie oft aktualisierst du Dokumentation, lieber Ralf?

Ich persönlich?

Ja, also ich lasse die Dokumentation tatsächlich aktualisieren und das ist jetzt seit kurzem tatsächlich mehrmals täglich, weil es klot macht für mich.

Aber vorher muss ich zugeben, gewinnt immer der Code, die Funktionalität.

Der DOCSIS-Code-Ansatz ist ja schon ganz nett, weil man dann gucken kann, du in dem Pull-Request, ja, du hast zwar Tests drin, aber die Dokumentation, hätte man die vielleicht auch anfassen können?

Die Prozesse geben das nicht so ganz her, oder?

Wie ist deine Erfahrung?

Ja, ich meine, es ist ja häufig so vielfältig, ganz einfach, wie man Verbrechen an der Dokumentation begehen kann oder generell an einer Dokumentation und einem allgemeinen Wissensstand.

Man muss sich ja nur vorstellen, ich kenne Projekte, ich kenne Umfelder, da hast du auf der einen Seite einen Confluence, hast aber gleichzeitig auch noch einen Sharepoint und irgendwie matcht da nichts.

Das andere ist vielleicht älter, aber man weiß es nicht genau.

Und das ist schon witzig.

Also erster Aspekt, auf jeden Fall Dokumentation in möglichst vielen verschiedenen Quellen verteilt haben.

Das ist dann doch eigentlich die ganz hohe Kunst, wenn man Dokumentation hat, aber die so aufgebaut hat, dass die so sinnlos ist, aber derjenige, der sie nutzen soll, aus verschiedenen Gründen das nicht kommunizieren kann.

Hörst du, was ich denke?

Also zum einen kannst du ja voll viele Fachbegriffe unterbringen, die du nicht erklärst.

Und derjenige, der es liest, kommt sich irgendwie dumm vor, wenn er das fragen muss.

Ja, das ist jetzt auch ein ganz schöner Effekt eigentlich.

Das hast du ja auch häufig in Meetings irgendwie.

Oh Gott, was erzählen die?

Ich verstehe das nicht.

Kein anderer meldet sich, wenn ich das jetzt nachfrage, dann halten mich jetzt alle für blöd.

Also da spielen auch ganz andere Effekte quasi mit rein.

Aber wie gesagt, du kannst es wunderbar verteilen.

Das ist das eine.

Und dann haben wir nochmal, deswegen habe ich so ein bisschen auf die Aktualisierung hingewiesen, du kannst ja auch die Dokumentation in unterschiedlichen Ständen belassen.

Was heißt das?

So ein Security-Konzept aus dem Jahr 2019 kann ja heute immer noch relevant sein, unter Umständen.

So eine Architektur, wenn du dir so eine alte Kathedrale anguckst, der Grundriss ist immer noch der gleiche.

Warum soll das nicht auch in der Software funktionieren?

Eben, die Software ist ja auch für die Ewigkeit gebaut.

Deswegen sehe ich da eigentlich auch keinen Grund, da irgendwas zu ändern dran.

Und wie gesagt, das ist dann jetzt quasi so, wie sich jetzt Software materialisiert im Prinzip.

Und da gibt es auch noch ein ganz tolles Tool oder ganz tolles Werkzeug, was Dokumentation irgendwo betrifft.

Stell dir vor, du gehst ins Confluence, denkst dir so, hier Anforderungen für das und das Release, klickst dann drauf und dann hast du da eigentlich nichts stehen, außer einen kleinen To-Do.

Und jetzt muss ich auch sagen, das ist ein Werkzeug, das ich immer wieder gerne benutze.

To-Do, ja, irgendwer wird es irgendwann unter irgendwelchen Umständen bestimmt machen.

Gibt es da ein Plugin für Confluence?

Ein To-Do-Plugin?

Bestimmt.

Also ich kann mir nicht vorstellen, dass das jetzt nicht irgendwie gesunder Menschenverstand wäre, genau das zu verwenden.

Also den Need gibt es auf jeden Fall.

Das bringt mich gerade auf Ideen.

So ein Plugin bauen, was dir hilft, im Wiki eine möglichst schlechte Dokumentation aufzubauen.

Das wäre doch so ein Giveaway für deinen Talk.

Ja, total.

Für die praktische Anwendung nehmt das.

Ja, super.

Danke.

Dann kann ich auf jeden Fall schon mal das mit auf eine Reise nehmen.

So ein Checker, der sagt, du hast jetzt hier fünf Seiten Dokumentation geschrieben, aber die Links funktionieren alle.

Willst du nicht ein paar Broken Links einbauen?

Ja, oder du hast hier eigentlich die vier, fünf Seiten ganz gut geschrieben, aber es ist viel zu wenig Prosa.

Pack doch mal ein bisschen mehr rein.

Verdreifache einfach mal den Umfang.

Ohne Überschriften oder so.

Da sagst du was, weil hier haben wir den Kommentar.

Ich warte immer noch darauf, mit UML-Diagrammen begrüßt zu werden und mit Prosa.

Hoffnung kann man haben, aber ich sehe es nicht.

Also ich habe manchmal auch so das Gefühl, wenn man mal so UML-Diagramme sieht, dann heißt ja, wir haben hier eine Architektur als UML-Diagramme.

Die sind aber in dem und dem Tool und da kommst du nicht drauf, weil die Lizenz zu teuer ist.

Da musst du den Peter fragen.

Aber der Peter hat keine Zeit, da sind wir wieder am Anfang.

Und manchmal ist die Komplexität von solchen Visualisierungen verschiedener Abstraktionsebenen und so auch nicht ganz einfach zu lesen.

Da kann man sicher auch noch einiges einbauen, dass Diagramme nur suggerieren, die Wahrheit wieder zu spiegeln.

Ja, erstens das und vor allen Dingen, man muss sich ja auch nicht zwingend an irgendwelche Diagramm-Standards halten.

Solange man es selber versteht, werden es auch alle anderen verstehen.

Das kann auch nochmal ein Aspekt sein.

Einfach eine Legende drunter packen.

Ich glaube, das halte ich auch für gar nicht mal so unselten, dass man da irgendwelche Dinge, Klassendiagramm nennt, aber es ist tatsächlich eher ein getuntes Entity-Relationship-Modell oder sowas.

Keine Ahnung.

Kann man alles machen, Bild durchmischen, hauptsächlich für viel Verwirrung sorgen.

Das ist jetzt quasi so der Aspekt der Dokumentation, die vielleicht schriftlich niedergelegt ist.

Wir reden ja jetzt hier quasi noch von irgendwelchen Softwaren wie Sharepoint oder Confluencer oder irgendwelchen Wikis.

Du hast ja vorhin schon das Wiki in drei Ordnern ausgedruckt.

Natürlich gibt es irgendwas Gedrucktes, vielleicht noch in irgendwelchen historisch gewachsenen Projekten oder Umfeldern.

Und das andere ist natürlich auch noch das Wissen, das eigentlich hätte dokumentiert werden sollen, was in den Köpfen der Menschen verteilt ist.

Das haben wir auch.

Also geh in ein Projekt rein, frag drei Leute oder vier Leute und du kriegst vier unterschiedliche Aussagen zu irgendetwas.

Und das muss man auf jeden Fall fördern an der Stelle.

Da hatte Eberhard ja auch eine Folge über das Paper von Peter Nauer von 85, die Code-Theory, dass eben viel in den Köpfen über den Code drin ist und dass es schwierig ist, wenn jemand Neues reinkommt, das zu transferieren.

Ich war gerade schon geneigt, dich zu fragen, ob du Erfahrungen hast, wie man das gut macht.

Aber wir wollen ja gerade darüber reden, wie man es gescheit macht, dass das Projekt mit hoher Geschwindigkeit gegen die Wand fährt und der Allerhöchste.

Ja, genau.

Wir bekommen den Code einfach nicht aus den Köpfen raus.

Wir kriegen das Wissen nicht aus den Köpfen raus.

Warum auch?

Was in den Köpfen ist, muss man nicht unbedingt zwingend niederschreiben.

Das heißt also, so etwas wie Code ist die Wahrheit und den braucht man nicht zu dokumentieren.

Das spielt da auch mit rein, oder?

Ja, mit Sicherheit.

Das setzt natürlich auch voraus, dass man möglichst schlechten Code schreibt.

Das wäre auch noch eine dieser potenziellen Regeln, wenn wir so ein bisschen technischer werden.

Vielleicht abschließend zum Themenkomplex Dokumentation.

Wenn man den konträren Ansatz wählt und sagt, Dokumentation ist schon geil, wir planen das möglichst groß.

Wir planen ganz viel und machen das.

Da ist ein gutes Beispiel, so sehr ich es schätze, Arc42.

Es gibt ja eine gewisse Struktur vor und dann haben wir hier so ein kleines Stück Software und das blasen wir jetzt so komplett auf und packen das dann quasi in dieses Format rein.

Großdenken.

Aber auch hier, man kann auch ganz viele Kapitel in Arc42 mit einem To-Do versehen, Work in Progress lassen, nicht mehr updaten, irgendwelche Sichten drauf vertauschen.

Das lädt ja auch wunderbar ein, um triebig zu sein.

Das ist ja auch so schön, wie ein Formular zu verwenden, dass man es nimmt und von vorne nach hinten befüllt.

Guck mal, das sind erst 45 Seiten.

Unser Standard ist mindestens 50 Seiten.

Kannst du da nicht noch ein bisschen mehr?

Jetzt kannst du dir alle möglichen Qualitätskriterien noch generieren lassen.

Aber Sarkasmus würde ich nicht nennen.

Ich würde eher Beobachtung der Welt nennen.

Ja, ich habe das jetzt aber mal so aufgenommen, dass man vielleicht noch mal ein bisschen zwischenstreuen sollte, dass das, was wir jetzt hier erzählen, tatsächlich nicht ganz ernst gemeint ist, sondern es geht ja tatsächlich darum, wir nehmen die andere Sicht ein, wir überlegen uns, was können wir machen, dass das Projekt scheitert, um daraus dann die Probleme mal zu zeigen, damit dann jeder sich daraus ableiten kann, wie es dann doch besser geht.

Aber vielleicht ist ja auch der eine oder andere dabei und sagt, wieso, das funktioniert doch so, wie das gerade erzählt wird.

Dann würde ich mich interessieren, was da das Feedback ist.

Ja, es ist ja im Grunde so, dass diese Regeln ja so ein bisschen auch da sind, um da auch mal ein bisschen zur Selbstreflexion einzuladen.

Weil häufig sitzt man in diesen ganzen Projekten so ein bisschen länger drin und man verliert manchmal so ein bisschen die Distanz dazu.

Und alles mit einer gesunden Distanz mal zu betrachten und zu denken, okay, dass wir das machen, das funktioniert eigentlich gar nicht so richtig, obwohl wir es tun.

Und ich überrasche mich ja selbst häufig dabei, wenn dann schreibe ich was, dann hänge ich da ein To-Do rein.

Mache ich es wirklich mal irgendwann?

Natürlich mache ich das, na klar.

Aber es sind solche Dinge.

Natürlich ist das alles ein bisschen überspitzt an der Stelle.

Aber wie gesagt, es sind ja Dinge, die da draußen passieren oder passiert sind und irgendwie immer wieder passieren.

Da fragt man sich, warum?

Und wo ist es eigentlich besser?

Aber das ist doch jetzt so auch richtig schön.

Das sieht man ja häufig, dass Teams Praktiken übernommen haben und es dann machen.

Weil das haben wir so gesehen, das machen die anderen auch, das machen die erfolgreichen Teams.

Microservices, weil Netflix und ja, unser Team hat so richtig schöne Microservices, kleine Services.

Unser Team hat 50 Microservices.

Das geht dann in die Richtung Cargo-Kult, oder?

Man macht es nach und man weiß nicht, warum.

Ja, aber man hat irgendwo gesehen, dass es funktioniert und denkt sich halt, wir adaptieren das für uns und denken gar nicht darüber nach, passt das in den Kontext?

Passt das überhaupt da rein?

Da habe ich noch ein anderes, ein kleineres Beispiel dafür, was so ähnlich ist.

Es gibt ja auch so kognitive Verzerrungen, diverse Biases und so.

Es gibt auch so ein Survivorship-Bias und der geht eigentlich auch in diese Richtung, dass man gewisse Dinge ohne das große Hinterfragen adaptiert.

Und das Beispiel dafür wäre, wenn wir uns vorstellen, wir sind in einem Umfeld mit mehreren agilen Teams, mehreren Scrum-Teams und man misst ja häufig den Erfolg.

Man misst den Erfolg, Sprintziele werden erreicht, der Burn-Down startet schön aus, etc.

Und dann kommt man hin, oh, hier ist ein Team, das ist immer erfolgreich, das erreicht seine Sprintziele.

Und was setzt das jetzt ab von allen anderen Teams?

Ah, es wird nicht dokumentiert.

Also andere Teams, geht hin, hört auf zu dokumentieren, dann werdet ihr ebenso erfolgreich wie dieses Team.

Und dann wundert man sich am Ende, warum hat das jetzt nichts gebracht?

Jetzt sind sie genauso wenig erfolgreich wie vorher, also genauso wenig erfolgreich und die Doku fehlt.

Und das ist so ein guter Fall dafür, dass man eigentlich auf das vermeintlich Offensichtliche schaut.

Ah, das hilft uns vielleicht, wir können das hier übernehmen.

Aber jetzt vielleicht gar nicht weiß, das ist hier vielleicht eine hohe psychologische Sicherheit im Team, hohes Kontextwissen, hohes verteiltes Wissen innerhalb der Köpfe.

Das haben die anderen Teams eben nicht.

Es ist schon so ein bisschen ähnlich gelagert an der Stelle.

Wir übernehmen irgendwas, wir haben irgendwo gesehen, ah, das ist voll gut, das ist vielleicht eine Best Practice.

Andere haben das gemacht oder ich habe das in einem anderen Projekt schon mal gemacht.

Wir nehmen das hier drauf, setzen uns drüber und wundern uns, warum es nicht so vielleicht vollständig funktioniert, wie wir uns das vorgestellt haben.

Aber das wäre ja dann auch sicher hilfreich, wenn man so ein Team so stafft, dass man so einen super einfachen Developer drin hat, der die ganzen Issues rockt und notfalls eben auch von den anderen das Ganze abhängt und der hat dann die ganze Dokumentation im Kopf.

Und deswegen brauche ich dann auch keine Dokumentation, oder?

Macht wahrscheinlich total Sinn, bis der dann auch das Team verlässt, weil er nicht den Pour-out hat, sondern den Burn-out.

Ja, ich meine, das ist ja auch so ein Führungsding, häufig auch Märtyrertum zu belohnen.

Denkt man, oh, der eine, der reißt das für alle hier irgendwie raus.

Da verlassen wir uns auf den, schaufeln extra Arbeit zu.

Und wenn die Person dann eben nicht mehr da ist, ja, dann haben plötzlich alle ein Problem.

Und das ist natürlich auch falsch, Workload bei einzelnen Leuten da zu belassen.

Passiert aber auch häufig viel zu oft, auch viel zu häufig.

Sag mal, du hast den Burn-down-Chart angesprochen.

Wie muss der denn aussehen?

Also ich sehe meistens den, der so horizontal ist und dann einen Tag vor Sprintende runterfällt, oder?

Das war doch so Sinn und Zweck.

Das ist so, Hauptsache am Ende sind wir quasi bei Plus Minus Null am Ende gelandet.

Hat ja auch verschiedenste Gründe.

Dinge werden erst zum Sprintende abgenommen oder werden zum Sprintende erst fertig.

Ist ja auch immer schön, wenn wir hier noch so kleine Buckel haben.

Wir sind mit, was weiß ich, 40 SPS reingestartet.

Ach Gott, über Agilität oder Scrum könnte ich eine ganze Stunde labern.

Und dann wächst das erst mal wieder an, bevor es erst mal so runter geht oder erst mal wirklich horizontal bleibt.

Auch ein interessantes Instrument.

Ich versuche mich gerade so ein bisschen diplomatisch auszudrücken.

Ja, ich bin auch gerade so ein bisschen, ich verliere mich so im Sarkasmus, weil ich weiß jetzt auch nicht.

Ich glaube, Stephan Schmitt sagt, ja, fünf Microservices pro Entwickler, damit bringe ich das Projekt zum Scheitern.

Ich glaube, das ist so rumgedacht, wohingegen hier der Kommentar plant UML ist eine gute Idee, wenn man jemanden mal kotzen lassen will.

Das finde ich spannend.

Das würde ich ja ganz gern noch mal so ein bisschen tiefer legen, weil ich glaube, das geht dann auch so ein bisschen in die Richtung.

Plant UML ist bis zum gewissen Grad ganz gut, wenn ich mal so kleine Diagramme visualisieren lassen möchte von der Maschine.

Aber wenn ich es übertreibe, dann geht es wieder nach hinten los, wenn ich da in das Rabbit Hole reingehe und die Styles anpasse und das Diagramm alles plant UML als Modell ansehe.

Das ist die Frage, was du irgendwie erreichen willst.

Wenn am Ende es eigentlich war, du willst dann irgendwie wirklich das Diagramm erstellen, du hast das als Aufgabe bekommen und 80 Prozent ist dann quasi in diesem Rabbit Hole dann an Zeit reingeflossen.

Das muss man im Verhältnis sehen.

Das ist immer eine Frage der zur Verfügung stehenden zeitlichen Ressourcen.

Neil Ford hat mal gesagt, Entwickler werden von Komplexität angezogen wie Motten vom Licht, meistens mit dem gleichen Ergebnis.

Sie verbrennen sich.

Das ist aber diese Rabbit Hole, oder?

Guck mal, hier kann man noch und das macht gerade so viel Spaß, das zu konfigurieren.

So ein Erlebnis hatte ich auch selber schon mal.

Da ging es ein bisschen um das Thema Defect Management.

Dann habe ich gedacht, das klingt interessant und dann plötzlich tauchst du voll ab.

Häufig sind das auch gerade Dinge, die erst mal von außen her gesehen banal wirken, aber wo du ganz schnell dann wirklich abtauchen kannst und was sich auch echt viel Zeit kosten kann an der Stelle.

Wenn wir von Zeit reden, dann haben wir wieder von I Am The Slime, interessanter Name.

Der spielt aber auch ein bisschen Parkinson’s Law mit bei dem Burndown Chart, der ganz am Ende runtergeht.

Parkinson’s Law, wenn ich das richtig zuordne, war das, wo man sagt, das Problem nimmt sich immer die zur Verfügung stehende Zeit.

Wenn der Sprint eine Woche ist, dann schaffe ich es eben in einer Woche.

Wenn er zwei Wochen ist, dann mache ich es eben in zwei Wochen, aber ich verbrenne die Zeit auch irgendwie.

Ja, ist das dann irgendwie so eine Art selbst erfüllende Prophezeiung auch, wenn ich da reingehe und denke, es dauert eine Woche?

Das ist ja auch diese Scotty-Regel im Prinzip.

Wenn du sagst, ich brauche zwei Wochen dafür und weißt eigentlich, dass es nicht so lange dauert, aber damit es wenigstens so wirkt, das hätte man ein Wunder vollbracht.

Aber das kann natürlich sein, wenn du dich selbst ein bisschen entweder die zeitlichen Freiheiten lässt oder aber dich selbst nur Druck setzt, dass das durchaus auch Auswirkungen hat, wie lange du wirklich für etwas brauchst.

Aber ich glaube, die Scotty-Regel müssen wir auch noch erklären.

Das ist so unsere Generation.

Wir haben das mitgenommen in jeder Folge von Raum für Enterprise.

Da gab es ein Problem.

Scotty hat gesagt, ich brauche acht Stunden, du hast aber nur vier.

Gut, ich mache zwei.

Genau.

Ja, das war immer der Running Gag.

In unserer Generation sind wir so alt, Ralf.

Wir haben eine ähnliche Bartfarbe.

Stimmt, aber du hast noch volleres Haar obendrauf als ich.

Ja, soll ich es mal abnehmen?

Lass mal.

Ja, also wie gesagt, ja.

Die Lösung eines Problems, kann ich würde ich mitgehen.

Jetzt hat hier einer, glaube ich, am Handy getippt.

Meine drei Hauptprinzipien heißt es, glaube ich.

Bist du sicher?

Kiss, Dry, Jagdnie.

Würdest du sagen, das hilft, das Projekt an die Wand zu fahren, oder würdest du eher sagen?

Ich dachte jetzt gerade, don’t repeat yourself.

Das ist so eine Sache im Prinzip.

Man lernt doch nur durch Wiederholung.

Ich glaube, wenn man es exzessiv anwendet, kann das auch durchaus Aspekte sein, die dabei unterstützen, ein Projekt zumindest zu blockieren oder zumindest den Fortschritt ein bisschen aufzuhalten.

Du kommst ja auch aus der Java-Welt und ich habe da immer so beobachtet, es gibt so einige Design-Prinzipien.

Mit denen kann man doch eigentlich auch viel anfangen, oder?

So die Naming-Conventions zum Beispiel und auch wenn die Leute die Challenge haben, wie bei der Bingo-Card, jedes bekannte Design-Prinzip in die Software einzubauen.

Damit kann man doch was erreichen, oder?

Ja, auf jeden Fall.

Auf vielfältige Art und Weise.

Wenn du dein Projekt wirklich sinnvoll an die Wand fahren willst, dann entwickle einfach erst mal schlecht Software.

Wobei ich jedem Entwickler unterstelle, wir alle können, wenn wir wollen, uns anstrengen, schlecht entwickeln.

Also auf jeden Fall.

Da gibt es verschiedenste Möglichkeiten.

Das reicht davon, dass wir irgendwann mal kleine, feine, in sich geschlossene Methoden haben, die dann aufgebläht werden mit irgendwelchen Exceptions, die gefangen werden, mit irgendwelchen Anforderungen, die reingebastelt werden bis hin zum Feature-Toggling.

Da brauchst du ja im Grunde auch technische Schulden mit auf mit solchen Geschichten.

Das fängt doch mit der Sprachwahl schon an.

Für Perl gibt es doch gar keinen Obfuscator, weil es schon obfuscated ist, oder?

Das ist interessant, weil ich Ende der 90er anfing und dachte, ich mache Online-Gaming und ich brauche einen Clan, eine Webseite.

Da habe ich mir gedacht, dann probiere ich mal mit irgendwas zu schreiben.

Ich habe mir dann so ein Perl-Buch gekauft und es war eine Katastrophe.

Da habe ich mir gedacht, ich steige erst gar nicht in die IT ein.

Aber es wäre mal interessant, ob es eine repräsentative Umfrage gibt, wo Perl eigentlich überhaupt bei den Sprachen steht.

Müssten wir mal Claude fragen.

Ja, genau.

Wir kriegen hier schon Feedback, dass wir ein bisschen weniger Smalltalk, ein bisschen mehr zielgerichtet arbeiten sollten.

Ich genieße es aber gerade so ein bisschen.

Das ist das Schlimme.

Wenn wir beide zusammenkommen, gibt es bedauerlicherweise relativ viel Smalltalk.

Ja, das ist nicht bedauerlich.

Das macht Spaß.

Ich will hier gerade noch einen anderen Kommentar.

Information-Hiding, um sich unabkömmlich zu machen.

Ich finde auch, die Komplexität hat ein bisschen Komplexity Cells.

Jemand, der komplexen Code schreibt, ist meistens hoch angesehen, oder?

Wow, der hat das verstanden, der kann das.

Ja, auf jeden Fall.

Es war schwer, diesen Code-Stück zu schreiben.

Es war auch schwer, das zu verstehen.

Das würde ich auch so ein bisschen in den Themenbereich, wir entwickeln Software eher komplex hinzu, wir zelebrieren technische Schulden, reinpacken.

Weil, ja, das ist auch schon ein richtiger Aspekt, der in dem Kommentar gewählt wurde, dass man sich unabkömmlich macht.

Ob man sich damit eine jobbehaltende Maßnahme nicht auch irgendwo schafft.

Jetzt habe ich das gerade, der Kommentar ist schon leider weg.

Das war nochmal zu dem, was du eigentlich gesagt hattest.

Es war hart zu schreiben, dann soll es auch schwer zu lesen sein.

Das geht nochmal in die Richtung, deswegen hat es gerade eingefallen.

Obwohl, ich hatte es eher so ein bisschen gepolt auf die Leute, die, also nicht selbst, nicht man selbst.

Im besten Fall versteht man das, was man geschrieben hat, nach ein paar Wochen noch.

Aber gerade für die Leute, die sich vielleicht das zur Einarbeitung dann ansehen sollen, das für die möglichst komplex an der Stelle sein sollte, um auch hier, ja, wie soll ich sagen, dem Projekt nicht zuträglich zu sein.

Du machst ja auch ziemlich viel öffentlich, Blogposts, Artikel und so.

Geht dir das auch manchmal so, dass man irgendwann vor einem Problem sitzt und sagt, ich google mal und dann findet man seinen eigenen Artikel und merkt, oh ja, hätte ich eigentlich wissen sollen?

Oder geht noch mehr das so?

Das hatte ich tatsächlich mal gehabt, aber in einem komplett anderen Zusammenhang von vielen, vielen Jahren.

Als ich da einen Artikel von mir, der im Java Magazin veröffentlicht wurde, plötzlich in irgendeine Bachelorarbeit aufgetaucht ist, die im Netz veröffentlicht wurde, die wurde da referenziert.

Das fand ich ganz spannend, aber das ist lange her.

Aber auch hier ganz interessant, dann liest du diese Sache noch mal und denkst dir zum Einen, was wollte ich damit eigentlich sagen?

Ich glaube, darauf zielt das so ein bisschen ab.

Und eigentlich sehe ich das jetzt völlig anders.

Das sind die beiden interessanten Sachen.

Das ist, denke ich, das wirst du auch an der Stelle haben, wenn du als Entwickler nach einem Jahr noch mal in den Code reinschaust.

Du hast dich ja selber weiterentwickelt.

Oder wenn du angefangen hast, irgendwann mal Architekturdiagramme zu bauen und guckst da noch mal ein, zwei Jahre drauf.

Natürlich verändert sich das.

Seitdem denkst du auch, ich würde das jetzt eigentlich komplett anders machen.

Das ist so ein bisschen die menschliche Erfahrung, die die Entwicklung einfach so mit reinschlägt.

Wollen wir noch mal schauen, dass wir ein bisschen Struktur reinbringen?

Hast du noch einen spannenden Punkt, den du mitgebracht hast?

Ja, wir haben eigentlich sehr viele Punkte jetzt sogar so ein bisschen mal angeteast.

Wir sind die ersten ein, zwei Punkte durchgegangen.

War das unerträgliche Willkommen oder schlecht dokumentieren?

Wir haben im Grunde jetzt auch schon das Thema technische Schulden so ein bisschen angesprochen.

Auch der unlesbare oder schlechte Code.

Meetingkultur.

Das ist auch etwas ganz Interessantes.

Ja, leg mal los.

Meetingkultur.

Das ist auch tatsächlich etwas, wo ich ein bisschen lernen musste.

Einfach so ein Meeting aufzusetzen.

Leute einzelladen, keinen Einladungstext.

Das ist schon das Minimalste, wenn keiner weiß, warum irgendwo irgendjemand drin ist.

Wenn du dann wirklich dafür sorgen willst, dass es zu Problemen kommt oder zu Unklarheiten, dann am besten immer ein Meeting ohne Agenda, ohne Moderation, ohne Ziel, was wir haben wollen.

Am besten ruft man eigentlich immer so ein Meeting ein und formuliert sich so ein Ziel.

Die Fragen zu dem und dem Ticket sollen am Ende dieses Meetings geklärt sein, zum Beispiel.

Was häufig aber noch einmal passiert in vielen Projekten oder in vielen Umfeldern.

Am Ende sitzt man zusammen und denkt, okay, jetzt haben wir hier eine Stunde ein bisschen was geredet.

Eine oder andere waren die ganze Zeit gemutet.

Ich denke, wir werden uns in einer Woche noch einmal hier zusammenfinden und über das Thema weitersprechen.

Und auch dann bewegst du dich plötzlich in einem Teufelskreis.

Ich denke, das kennst du mit Sicherheit auch aus diversen Meetings aus deiner langen Berufslaufbahn.

Ja, ich kenne das so.

Vor allem, was ich immer liebe, ist, wenn man doch merkt, auch ohne Agenda, ohne Ziel des Meetings hat man schon 20 Minuten vor Ende das Ziel erreicht.

Alle sind sich einig.

Dann sagt man aber doch noch, was machen wir jetzt noch, die 20 Minuten? Über was diskutieren wir noch?

Das finde ich immer spannend, wenn man versucht, den Raum zu füllen.

Auch das gibt es.

Statt das einfach mal zu lassen.

Was dazu passt, ist im Prinzip, du planst Meetings.

Du denkst auch, wir brauchen ganz viel Zeit.

Ich plane hier mal zwei Stunden ein für zwei, drei Agenda-Punkte.

Und dann bist du, wenn du dann nach 20 Minuten fertig bist, immer so viel Zeit.

Action Point, Follow-up Meeting.

Das sieht man so häufig.

Das geht in die richtige Richtung.

Man muss sich im Grunde auch immer vorstellen, je mehr Meetings stattfinden, desto schlechter ist die Qualität des Projekts.

Das grundlegende Problem ist, du bindest einen ganzen Haufen Menschen für eine gewisse Zeit X.

Zwei Dinge werden sich nicht überlegt.

Müssen diese ganzen Menschen mit dabei sein?

Das klingt so ein bisschen blöd.

Brauchen wir wirklich die Meinung eines Jedes, von dem wir glauben, dass er jetzt da drin ist?

Und gleichzeitig wird auf der anderen Seite nicht reflektiert, kann ich als Person, die eingeladen ist, eigentlich sinnvoll dazu beitragen?

Das finde ich auch so ein bisschen der Extreme.

Man tendiert häufig dazu, einfach mal die große Runde.

Plötzlich hast du 20 Leute drin sitzen, aber nur drei diskutieren.

Der Rest hört zu.

Das ist auch nicht zielführend, aber man kann natürlich einen netten Kaffee dabei trinken.

Oder man schickt das in Gruppenpostfächer, dann wird es weitergeleitet.

Eigentlich hat man gedacht, man hätte nur drei, vier Leute da sitzen.

Plötzlich explodiert der Teilnehmerkreis an der Stelle.

Plötzlich hast du Leute drin, die du gar nicht drin haben wolltest.

Da muss man so ein bisschen mit Fingerspitzengefühl rangehen und sich überlegen, was will ich mit dem Meeting, was soll am Ende bei rumkommen und wen möchte ich erreichen oder wessen Meinung brauche ich oder wessen Expertise?

Du hast gerade so nebenbei den Kaffee erwähnt.

Ich glaube, Kaffee, Kekse, bequeme Spüle fördern das auch, dass das Meeting sich einfach in die Länge zieht, oder?

Ja, oder Popcorn, wenn du weißt, da werden sich die zwei bestimmten Köpfe wieder streiten.

Ursprünglich hat man ja mal die agilen Stand-ups genannt, damit die Leute es möglichst unbequem haben und nicht mit dem Kaffee da sitzen und sagen, oh ja, jetzt höre ich mir das mal an und brate hier meine Zeit.

Das ist, glaube ich, auch ein Aspekt, der durch die Remote-Arbeit ein bisschen verloren gegangen ist.

Wahrscheinlich hat nicht jeder zu Hause einen Tisch zum hochfahren, um sich hinzustellen.

Ich musste mal ein bisschen untersuchen, welche Form von Meeting mehr zur Laberei einlädt.

Ob das wirklich so das Teams-Meeting ist oder ob es das Meeting vor Ort ist.

Das ist, glaube ich, eine ganz interessante Studie, die man da anfertigen könnte.

Ich finde auch, dass sich Entwickler oft schlecht auf Meetings vorbereiten.

Sie hassen Meetings einfach, weil sie die lieber programmieren.

Auch unprofessionell kann das verstehen, aber das spielt halt auch mit rein, wenn ich mich nicht vorbereiten kann, weil keine Agenda vorhanden ist.

Dann wird es spannend, weil sie lieber programmieren.

Ich hatte mal so eine Situation, wo mich ein Projektmanager als Techie in jedes Meeting mit reingenommen hat.

In jedem Meeting habe ich gesagt, das müssen wir machen, jenes müssen wir machen und sonst was.

Am Freitag, nachdem ich die ganzen Tage mit Meetings verbracht habe, hat er mich dann gefragt, wo wir denn jetzt stehen.

Ich habe nachgedacht und gemeint, du hast schon gemerkt, dass du mich den ganzen Tag, die ganze Woche in Meetings reingezogen hast.

Wo hätte ich irgendetwas umsetzen können?

Da war es dann spannend, dass er mir erklärt hatte, und das habe ich so für mich mitgenommen, man kann in Meetings reingehen, ohne dass man Aufgaben mitnimmt.

Da bin ich als Techie nicht gewöhnt.

Okay, das können wir mal so stehen lassen.

Das ist ein interessanter Aspekt.

Man kann auch in Meetings reingehen, ohne direkt Aufgaben mitzunehmen.

Naja, also wenn ich zum Beispiel nur moderiere und vielleicht im Meeting noch verteile.

Ich fände es auch interessant, dass hier Tobi Ziegler, wenn ich das richtig lese, sagt, ja es geht auch umgekehrt.

Management schlecht vorbereitet, Entwickler gut vorbereitet.

Also ich sehe schon, das wird unterschiedlich wahrgenommen.

Wahrscheinlich macht es Sinn, wenn sich jeder gut vorbereitet.

Ja, jeder bereitet sich gut vor und hat auch nicht zu viele Meetings.

Irgendwo muss der Sweetspot dazwischen sein.

Klar, es gibt unterschiedliche Rollen in Projekten.

Die einen Rollen haben mehr Meetings.

Das liegt in der Natur.

Die anderen haben weniger Meetings.

Aber die Meetings, die man vielleicht zusammen hat, da sollte man sich auch darüber unterhalten, wie man diese gestalten möchte.

Wenn man es nicht macht, dann kann es auch schnell passieren, ich habe den ganzen Tag nur Meetings, da habe ich gar keine Lust drauf.

Motivation sinkt, Produktivität sinkt und wir schaffen es auf jeden Fall, vielleicht unter die 19 Prozent zu kommen.

Sweetspot, da sagst du jetzt gerade was.

Wahrscheinlich kann man ja auch ein Projekt gefährden, in dem man die Teams zu groß stafft.

Umso größer, umso mehr Kommunikation.

Da hast du unfassbar viele Reibungsverluste.

Je nachdem kannst du auch die Möglichkeit haben, dass du dann Konstrukte hast, wo Menschen sich sehr geschickt auch verstecken könnten, wenn sie es wollen.

Kann durchaus sein.

Aber wie gesagt, Kommunikation ist ein großes Problem.

Organisation, je größer das Team, desto mehr Orga brauchst du drumherum.

Es sei denn, man schafft es tatsächlich, sich selbstorganisierte Teilteams zu bilden.

Kann mal funktionieren, muss nicht.

Ja, kann funktionieren, muss nicht.

Jetzt haben wir viel darüber geredet, wie man es nicht machen sollte.

Ich hoffe, dass keiner irgendwie ernst genommen hat.

Wollen wir die letzten drei Minuten nochmal nutzen und so grob zusammenfassen, was wir jetzt gesagt haben, wie man es eigentlich machen sollte, was wichtig ist?

Ja, ich glaube, so ein paar Key-Takeaways daraus sollten auf jeden Fall sein.

Die habe ich auch in der Regel in meinem Talk mit drin.

Wir Menschen neigen häufig dazu, die schlechten Dinge einfach entweder nicht zu sehen oder einfach hinzunehmen, zu denken, aber wir können ja eh nichts daran ändern.

Manchmal, und das hast du am Anfang eigentlich auch schon so benannt mit dem richtigen Begriff, manchmal ist es schon sehr hilfreich, einfach den Elefanten im Raum zu benennen.

Einfach mal darüber zu sprechen, das ins Gespräch zu geben.

Ja, unsere Meetings, die haben keine Agenda, das kostet uns nur Zeit und bringt uns nichts.

Vielleicht muss es mal jemand aussprechen, auch wenn es offensichtlich ist und man sich wundert, warum es keiner getan hat.

Manche trauen sich nicht, weil sie vielleicht auch denken, oh Gott, dann bin ich hier der Einzige, der erst querulant durch die Gegend läuft oder so.

Aber tatsächlich ist es durchaus hilfreich, mal die Dinge anzusprechen.

An der Stelle ist es auch noch ergänzend hilfreich zu sagen, ich suche mir jetzt Verbündete, die dann ähnlich ticken wie ich oder wie man selbst, dass man da wirklich mal so eine eigene, dass man Leute hat, die so ähnliche Ansichten haben, wie man vielleicht in einem Team arbeitet, wie man im Projekt arbeitet, wie man dafür der Arbeit sein sollte.

Wobei es hier, wenn man sagt, Verbündete suchen nicht darum geht es jetzt, den Putsch zu starten und das Management abzusetzen.

Nein, tatsächlich, um da eine gemeinsame Meinung zu bilden und vielleicht auch zu transportieren und vorzuleben.

Und am besten immer mit einem Vorschlag, wie es besser ginge.

Ganz genau.

Und das geht so ein bisschen in die Richtung, das habe ich in einem anderen Talk drin, nennt sich dann im Grunde Painpoint-Liste.

Beschreibe genau das, was das Problem ist.

Beschreibe, was löst dieses Problem an.

Also wozu führt dieses Problem?

Ungeplante Meetings kosten uns unfassbar viel Zeit, Entwicklerzeit.

Wir können stattdessen das und das machen.

Vorschlag, wie man es besser machen kann.

Ja, mal überdenken, wie die Meetingsstruktur ist, wie man eine falsche Agenda einführen kann.

Ich finde jetzt mit den Meetings ein schönes Beispiel, weil ich glaube, das kennt fast jeder.

Das wirklich mal aufzuzeigen, auch wirklich verschriftlichen die Dinge, auch komponizieren.

Nicht immer nur sagen, das ist Mist, das ist Mist, das ist Mist, sondern tatsächlich auch da in die Situation zu kommen.

Ja, es ist Mist, aber vielleicht gibt es ja einen Weg raus.

Das könnte ein Weg raus sein.

Aber kennst du das auch, dass man manchmal so ein Bauchgefühl hat und das gar nicht so richtig formulieren kann?

Also gerade jetzt dieser Hinweis, dass man einen Vorschlag geben sollte, wie es besser ginge.

Da muss man schon ein bisschen Erfahrung mitbringen, ein bisschen Hirnschmalz, dass man eben sagen kann, guck mal, in dem anderen Projekt haben wir das immer so gemacht und irgendwie ging das besser.

Ich meine, jetzt so eine Meetingagenda, theoretisch sollte jeder wissen, dass die mitgeschickt wird.

Praktisch sieht man die verdammt selten.

Da hat man sich vor drei Wochen mal kurz abgesprochen, ich stelle uns ein Meeting ein und das ist dann doch ohne Agenda, weil man hat sich abgesprochen und drei Wochen später fragt man sich, was wollten wir hier eigentlich besprechen?

Ja, richtig, aber da muss man auch aufpassen, wenn man jetzt wieder, da kommst du wieder in diese Denke rein, aber woanders hat es funktioniert, dann übernehmen wir das so einfach mal hier.

Das ist auch da mal so ein bisschen die kritische Hinterfragung.

Passt das wirklich?

Jetzt sprechen wir hier von etwas Organisatorischem, wenn es um etwas Technisches geht.

Wenn man den Hammer aus einem anderen Projekt nehmen will, um überall irgendwie, was weiß ich, irgendwo einzuschlagen, dann kann man das ja ganz geschickt lösen, gerade im Scrum-Up-Feld mit Spikes oder sonstigen Geschichten, dass man Dinge ausprobieren, aber nicht einfach ungeprüft komplett übernehmen.

Das ist aber wieder im Bereich Cargo-Kult, wenn ich nicht weiß, warum, dann mache ich es nur nach, so wie ich es gesehen habe und wundere mich, wenn ich nicht ganz so erfolgreich bin, wie das andere Team.

Genau, daher vielleicht mal ausprobieren, aber nicht wirklich dann als Gott gegeben einfach sofort umsetzen.

Zwei kleine Gedanken noch an der Stelle, weil ich glaube, bevor wir aus der Zeit rauslaufen, der eine Gedanke dazu, wenn wir im Endeffekt wirklich ausprobieren, überprüfen, ob es ganz klassisch funktioniert.

Das letzte Prinzip, manchmal gibt es Dinge, die wir nicht ändern können.

Die existiert immer, aber vielleicht, wenn wir fünf, sechs Flächenbrände haben, kann es vielleicht auch reichen, ein oder zwei zu löschen und das hat durchaus positive Auswirkungen auf den Rest.

Vielleicht so auf einer philosophischen Note, das mal abzurunden.

Perfekter Abschluss dieser Folge.

Wem das jetzt zu unstrukturiert war, dass wir hier einfach so darauf losgequatscht haben, strukturiert gibt es das im Dezember in Frankfurt auf den IT-Tagen als strukturierter Talk nochmal andere Punkte.

Eben wirklich strukturiert und mit dem Hinweis, wie es dann wahrscheinlich richtig geht, gehe ich mal davon aus, beziehungsweise etwas offensichtlicher.

Andreas, ich danke dir, dass du hier warst, dass wir darüber diesen auch leichten Fun-Talk mit Hintergründen, einem ernsten Hintergrund hier haben konnten.

Ja, und dann bleibt uns nichts anderes mehr übrig, als unseren Zuschauern ein schönes Wochenende, ein bisschen Abkühlung zu wünschen.

Auf jeden Fall.

Und wir sehen uns auf den IT-Tagen.

Alles klar.

Bis dann.

Bis dann.

Ciao.

Hier ein Hinweis in eigener Sache.

Softwarearchitektur im Stream live vor Ort.

Wir sind bei den IT-Tagen im Dezember in Frankfurt mit dabei.

Mehr Infos dazu und spezielle Rabattcodes für unsere Community findest du auf unserer Website software-architektur.tv.

Sei dabei, stell Fragen und komm auch gern auf uns zu.