# Strategic Project Delivery: Avoiding Systemic Failure

**Podcast:** Software Architektur im Stream
**Published:** 2026-07-08

## Transcript

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 gerne auf uns zu.
Ja, hallo und herzlich willkommen nach diesem schönen Intro zu einer weiteren Folge von Zauberer Architektur im Stream.
Heute zu Gast Andreas Monschau.
Wir haben das Thema, wie fährst du dein Projekt zuverlässig an die Wand?
Und Andreas ist da Experte im Zuverlässig.
Nein, du hast Erfahrungen gesammelt, wie man Projekte zuverlässig an die Wand fährt durch Beobachtung, oder?
Andreas, 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, aber so viele Projekte in verschiedenen Rollen wahrnehmen dürfen und bin mittlerweile, ich möchte nicht sagen zynischer Beobachter im Softwareprojektumfeld 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 viele Wiederholungen 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 man 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?
Naja gut, ich bin ja mit einem pädagogischen Auftrag unterwegs.
Das Wesentliche ist ja, wir sind ja alles Menschen, wir sind in unseren Softwareprojekten, haben unsere ganzen Rollen, wir sind Entwickler, wir testen, wir machen Frontend, wir machen DevOps, wir managen etc.
pp.
oder machen agilen Kram, alles Mögliche.
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 Dev Day in Dresden gehalten dieses Jahr und habe den dann direkt zweimal gehalten.
Da kam, bevor ich den das erste Mal gehalten habe, kam ich so, hier, viele Kunden jetzt gerade nicht sehen, wegen dem 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 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.
Und meine Theorie dazu ist, dass wir halt einfach alles Menschen sind und gerne sehenden Auges ins 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 das 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 vom 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, wie gesagt, 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 Karrieren.
Das ist ja unglaublich viel, was mit dranhängt.
Bleibt nochmal 50 Prozent übrig und diese Projekte sind zumindest mit irgendeiner Art von Problemen behaftet in unterschiedlichsten Ausbringungen.
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 und wenn es Schönreden ist.
Ja, ich glaube, die Projekte, die erfolgreich sind, sind häufig die schön geredeten oder die alten Scope-Änderungen hinter sich haben.
Scheitern kann in dem Kontext halt wirklich sein, ja, es ist so teuer, so aufgebildet, hier musste wirklich der Verstecker gezogen werden.
Hab ich persönlich, das muss ich mal kurz überlegen.
in der Form nicht erlebt.
Zwar von Projekten, die kurz davor standen, aber dann passierte halt das.
Aber wir definieren das um, machen nach dem Ende einen Erfolg draus.
Es mag es ja auch da draußen geben, die Projekte, die wirklich ohne Problematiken unterwegs sind, wo man am Ende sagen, boah, hier alle Ziele erreicht, Budget nicht überschritten, super, wir gehen jetzt dann quasi in den Wartungsmodus rein und Attacke.
Aber ich glaube persönlich, wo wir uns am häufigsten bewegen, das sind die Projekte, die grundsätzlich Probleme haben.
Aber 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, das ist auch, glaube ich, auch wieder so etwas Menschliches an der Stelle.
Wir erinnern uns ja häufig immer gerne an die schlimmen Dinge.
Und manchmal blenden wir die positiven Dinge einfach aus und 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.
Man guckt ja manchmal auf seine Projekthistorie 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, wonach gebessert 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.
Genau, und das kann man ja im Prinzip noch weiterführen.
Was könnte dann auch heißen, wenn wir hier alles wirklich abliefern, fristgerecht, auch vielleicht ein 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, ja, ja, ja.
Könnte.
Könnte, würde keiner machen.
Nein.
Ja, du hast mich ja im Prinzip schon mal gefragt nach so ersten Maßnahmen, wie man ein Projekt, sagen wir zumindestens, ruinieren könnte oder wie man das 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 Ansinn.
Andersrum wäre, da müsste ich ja wissen, wenn man es richtig macht.
Aber andersrum, wie gesagt, so ist es der Profi-Ansatz.
Ja, genau.
Destruktiv statt produktiv.
Naja, 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, dann 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 Vakanzen frei, Positionen müssen besetzt werden und hier kann man im Prinzip schon zu Beginn ansetzen.
ob es jetzt Junioren sind oder Senioren, die da jetzt umgesetzt werden müssen oder danach rücken, dass man dort von Anfang an schon ein, ja, ich setze es mal unter dem Urbegriff unerfreuliches Willkommen bereitet.
Dass man sich gar nicht vorbereitet auf diese Menschen, die da kommen.
Dass man eigentlich, ja, man weiß, ach, 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, fucht 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, neue 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.
Ja, genau.
Ich meine genau, das Notebook ist in vier Wochen da, aber jetzt die ganze Entwicklungsumgebung, das wird nochmal acht Wochen dauern, bis du da wirklich vollkommen arbeitsfähig bist.
Also es tröpfelt dann nach und nach rein.
Aber das ist ja quasi schon wirklich so dieses 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 in neue Projekte reinkommen, die haben ja erstmal 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.
Das müssen die dann doch mitbringen, dass sie sich zurechtfinden und eigenständig irgendwie die Kontakte finden und die Prozesse.
Genau.
Wieso soll man Händchen halten?
Die sind ja alle erwachsen.
Wir brauchen kein Onboarding-Kraft.
Doch Profis.
Profis.
Natürlich hochbezahlt.
brauchen wir da uns nicht so viel zu verausgaben.
Das heißt, wir haben also keinen echten Onboarding-Plan, wissen nicht, wo die Reise hingehen soll.
Und da kommen wir vielleicht gleich zu, aber es mischt sich hier auch schon so ein bisschen rein.
Vielleicht kommt ja irgendwann auch so der Zeitpunkt, wo sie vielleicht produktiv werden könnten, vielleicht, und wo man ihnen Aufgaben geben soll.
Weil es gibt bestimmt irgendjemanden ganz oben, der sagt, wir haben diese teure neue Ressource.
Darauf hinweisen, neue Entwickler sind Ressourcen, sind keine Menschen, sind Ressourcen oder Ressourcen, sind ja austauschbar.
Aber diese neue Ressource muss ja mit Aufgaben versorgt werden, denn sie kostet ja Geld.
Und dann ist auch wieder die Frage, welche Aufgaben gibt man da?
Irgendwie, ja, arbeiten wir halt irgendwie das ab.
Ich meine, klar, du kennst dich wieder mit der Fachlichkeit oder Technologie aus, aber guck es dir mal an.
Bis hin zu, ja, wir haben gerade keine Aufgaben für dich.
Guck dir mal ein bisschen Doku, kommen wir gleich auch noch zu.
Oder man gibt so völlig unterfordernde Aufgaben.
Da kennt man auch so, ja, wir müssen mal hier irgendwie eine Library updaten.
Mehr haben wir diese Woche für dich nicht.
Wir vertrauen dir nicht, dass du noch mehr kannst.
Und du machst bloß keine Fehler.
Denn wenn du Fehler machst, werden wir sie 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 da nichts bei.
Man erhöht vielleicht seine Frustrationstoleranz oder seine Geduld.
Ich meine, Langeweile ist auch was Gutes.
Da entstehen ja großartige Dinge draus.
Aber wenn ich mir jetzt vorstellen müsste, ich sitze acht Stunden rum, habe einen Kaffee, vielleicht keinen Rechner, weil der erst in drei, vier Wochen kommt.
Ja, du hast ja dann dein Handy.
Und da hast du sicher ein paar Spiele drauf.
Okay.
Ist dann aber wieder problematisch, wenn dann am Ende der ersten Woche vielleicht doch jemand aus dem Management kommt und sagt, okay, und, was haben sie schon gemacht?
Gut.
Ah, wo kann ich mich jetzt trauen, die anzuschwärzen, die mich ja 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 so Kritik an deinem Ansatz rüber.
Also sauberes, geplantes Onboarding mit Menschen, das wäre schon ganz gut.
Ja, aber 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 Kappemaschine 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 viele Fragen, aber keine Antworten, hat dann vielleicht Ansprechpartner bedannt bekommen.
Diese Ansprechpartner sind aber nicht erreichbar, weil sie 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, wer nicht beantwortet.
Was möchte man dagegen machen?
Ist natürlich schwerer, wenn alle im Office sind.
Da muss man sich unterm Schreibtisch verstecken, wenn man nicht vom Neuling irgendwie belästigt werden möchte.
Aber ja, die Maschine 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 Land unter ist, unterstützen.
Und dann ergibt sich das doch automatisch, dass man nicht die Zeit hat.
Richtig.
Natürlich ergibt das auch die Möglichkeit, einfach deinen Neuling schon komplett von Tag ein, 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 Leitzordner.
Genau, Leitzordner, alles Mögliche.
Man kann dann entweder zu wenig Aufgaben, unterfordernde, zu viele Aufgaben für den, 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 auf den 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.
Du hast ja schon direkt gesagt, da muss man sich schon direkt unter dem Tisch verstecken oder sonst wo.
wenn man vor Ort ist.
Übrigens, wir haben ja jetzt hier ganz viele, wie ich sehe, 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.
Und die erste Frage ist im Prinzip, wie viele dieser Regeln, die ich benenne, ich benenne meistens zehn Regeln.
Habt ihr selber schon erlebt?
Und danach gibt es dann noch auf dem zweiten Slide einen Freitext, wo man quasi seine eigene Erfahrung nochmal kundtun kann.
Und da ist alles dabei von, das geht dich gar nichts an, bis, ja, es ist so viel, das kann ich gar nicht, rezitiert.
Das ist hochinteressant, woran ich selber nicht denke oder selber noch nie erfahren habe.
Ja, wir hätten eigentlich so eine Bingo-Karte zum Selbstausdrucken irgendwie rausgeben können.
Ich finde 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 und den Unterschied zwischen ich mache gar nichts und Unterforderung.
Ich kann mir da schon was vorstellen, aber habe nicht so richtig die Die Begrifflichkeit dafür im Kopf.
Ja, ich glaube, es wird schon fast ein bisschen philosophisch an der Stelle.
Ich glaube, die Unterforderung ist dann gleichzeitig noch, da schwingt ein, oh, die trauen mir ja gar nichts zu mit.
Beim Nichtstun, na gut, die geben mir halt nichts.
Das kann ich mir schon vorstellen, dass man dieses Gefühl der Unterforderung wirklich sehr befüttern kann, wenn man wirklich solche Aufgaben oder ehrrührige Aufgaben übermittelt.
Also auf jeden Fall pro Tipp.
Hier kommt noch Burnout versus Boreout.
Ja, das ist dann die Unterforderung, wenn man sich langweilt und sagt, ja, okay, ich habe die zwei Sachen, die du mir gesagt hast, schon gemacht.
Was soll ich den Rest machen?
Ja, 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's mir.
Lies doch mal was Doku.
Ja, ach so.
Ah, Doku ist irgendwie auch so ein bisschen mein Thema.
Und meine Erfahrung ist, ja, ne?
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, genau.
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.
Also, ich lasse die Dokumentation tatsächlich aktualisieren und das ist jetzt seit kurzem tatsächlich mehrmals täglich, weil es Cloud macht für mich.
Aber vorher muss ich zugeben, gewinnt immer der Code die Funktionalität.
Der Docs-Code-Ansatz ist ja schon ganz nett, weil man dann gucken kann, du in einem 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 unter allgemeinem 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.
Fühlst 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 ja auch ein ganz schöner Effekt eigentlich.
Da 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 das 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 weiß ich?
Und 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, das ist auch für die Ewigkeit gebaut.
Also deswegen sehe ich auch keinen Grund, da irgendwas zu ändern dran.
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 ein ganz tolles Werkzeug, was Dokumentation irgendwo betrifft.
Stell dir vor, du gehst ins Confluence, denkst dir so, hier Anforderung für das und das Release, klickst dann drauf und dann hast du da eigentlich nichts stehen, außer einem kleinen To-Do.
Ja.
Und jetzt muss ich auch sagen, 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 Konfurenzen?
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.
Damit kann ich auf jeden Fall schon mal das mit auf meine Reisen 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 da mal ein bisschen mehr rein.
Verdreifache einfach mal den Umfang.
Ohne Überschriften.
Da sagst du was, weil hier haben wir den Kommentar, ich warte immer noch darauf, mal mit UML-Diagrammen begrüßt zu werden, 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 ja auch die Komplexität von solchen Visualisierungen, verschiedene Abstraktionsebenen und so, auch nicht ganz einfach zu lesen.
Da kann man sich ja auch noch einiges einbauen, dass Diagramme nur suggerieren, die Wahrheit wieder zu spiegeln, oder?
Ja.
Erstens das und vor allen Dingen, man muss sich ja auch nicht zwingend an irgendwelche Diagrammstandards halten.
Solange man es selber versteht, werden es auch alle anderen verstehen, bestimmt.
Das kann auch nochmal ein Aspekt sein.
Einfach eine Legende drunter packen.
Das halte ich auch für gar nicht mal so unselten, dass man da irgendwelche Dinge, was weiß ich, Klassendiagramm nennt, aber es ist tatsächlich eigentlich 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 irgendwie schriftlich niedergelegt ist.
Wir reden ja jetzt hier quasi noch von irgendwelchen Softwaren wie SharePoint oder Confluence oder irgendwelchen Wikis oder sonst irgendwie.
Du hast ja vorhin schon, wir haben dir 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, wer sein 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 du sollst auch viel verfördern an der Stelle.
Da hatte Eberhard ja auch eine Folge über das Paper von Peter Nauer von 85, die Code Theory, eben viel in den Köpfen über den Code drin ist und dass es schwierig ist, wenn jemand Neues reinkommt oder so, das zu transferieren.
Ich war gerade schon geneigt, dich zu fragen, ob du Erfahrung 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 jemanden fährt und allerhöchster.
Genau, deswegen, wir bekommen den Code einfach nicht aus den Köpfen raus.
Wir kriegen das Wissen nicht aus den Köpfen raus.
Ja, warum auch?
Und daher, was in den Köpfen ist, muss man auch nicht unbedingt zwingend niederschreiben.
Das heißt also, sowas wie Code ist die Wahrheit und den braucht man nicht zu dokumentieren, das spielt da auch mit rein, ne?
Ja, mit Sicherheit.
Setz natürlich auch voraus, dass man einen möglichst schlechten Code schreibt.
Wäre auch noch eine dieser potenziellen Regeln, wenn wir so ein bisschen technischer werden gleich an der Stelle.
Aber vielleicht abschließend zum Themenkomplex Dokumentation.
Vielleicht auch nochmal, 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.
Und da ist eigentlich ein gutes Beispiel.
So sehr ich es schätze, ARC-42.
Es gibt dir ja so eine gewisse Struktur vor und dann hast du 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 ARC-42 einfach mit einem To-Do versehen, Work in Progress lassen, nicht mehr updaten, irgendwelche Sichten drauf vertauschen.
Das lädt ja auch wunderbar ein, damit, wie soll ich sagen, umtriebig 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.
Und 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 ja noch generieren lassen irgendwie, also du selber nicht dran denkst.
Aber Sarkasmus würde ich es nicht nennen, ich würde eher so Beobachtung der Welten nennen.
Ja, ich habe das jetzt aber mal so aufgenommen, dass man vielleicht nochmal 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, das wird 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?
Man wüsste 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, weil man hat irgendwo gesehen, dass es funktioniert und denkt sich halt, wir adaptieren das für uns und denken gar nicht so nach, passt das in den Kontext?
Passt das überhaupt da rein?
Dann habe ich noch ein anderes, vielleicht so kleineres Beispiel dafür, was so ähnlich ist, weil im Grunde, es gibt ja auch so kognitive Verzerrungen, diverse Biasse und sowas, gibt es auch so Survivorship-Bias, und der geht eigentlich auch in diese Richtung, dass man gewisse Dinge ohne und es groß 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 Burndown 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?
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 man das jetzt nicht 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ß, ah, das ist hier...
Vielleicht eine hohe psychologische Sicherheit im Team, hohes Kontextwissen, vielleicht verteiltes Wissen innerhalb der Köpfe.
Das haben die anderen Teams eben nicht.
Und 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, sitzen uns drüber und wundern uns, warum es nicht so vielleicht vollständig funktioniert, wie Ja, 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 10-fach Developer drin hat, der die ganzen Issues rockt und notfalls eben auch von den anderen das Ganze abfä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 War Out hat, sondern den Burn Out.
Ja, ich meine, es ist ja auch so ein Führungsding, dann häufig auch Märtyrertum zu belohnen.
Denken wir, der einer, der reißt das für alle hier irgendwie raus, da verlassen wir uns auf den, schaufeln wir extra Arbeit zu und wenn die Person dann eben nicht mehr da ist, dann haben plötzlich alle ein Problem.
Und das ist natürlich auch falsch, Workload bei einzelnen Leuten dazu belassen.
Passiert aber auch häufig viel zu oft.
Oft viel zu häufig, wie auch immer.
Sag mal, du hast den Burndown-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.
Hauptsache, am Ende sind wir quasi bei plus minus Null am Ende gelandet.
Hat ja auch verschiedenste Gründe.
Dinge werden erst zum Spritende abgenommen oder werden zum Spritende erst fertig.
Ist halt auch immer schön, wenn wir hier noch so kleine Buckel haben.
Wir sind mit 40 SPS reingestartet.
Ach Gott, über Agilität oder Scrum könnte ich noch eine ganze Stunde labern.
Aber...
Und dann wächst das erstmal wieder an, bevor es erstmal runtergeht oder erstmal 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, Stefan Schmidt sagt, ja, fünf Microservices pro Entwickler, damit bringe ich das Projekt zum Scheitern.
Ich glaube, das ist so rumgedacht, wohingegen hier der Kommentar, Plan-Tuber-Mail ist eine gute Idee, wenn man jemanden mal kotzen lassen will.
Das ist, das finde ich spannend.
Also das würde ich ja ganz gern nochmal so ein bisschen tiefer legen, weil ich glaube, das geht dann auch so ein bisschen in die Richtung, Plan-Tuber-Mail 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 Du hast das als Aufgabe bekommen und 80% ist dann quasi in diesem Rabbit Hole an Zeit reingeflossen.
Muss man im Verhältnis sehen.
Das ist immer eine Frage der zur Verfügung stehenden zeitlichen Ressourcen auch.
Neil Ford hat mal gesagt, Entwickler werden von Komplexität angezogen wie Motten vom Licht, meistens mit dem gleichen Ergebnis.
Die verbrennen sich.
Das ist aber diese Rabbit Holes, oder?
dass, ah, guck mal, hier kann man noch.
Und das macht gerade so viel Spaß, das zu konfigurieren.
Ja, also ich meine, so Erlebnisse hatte ich auch selber schon mal.
Dann hieß es irgendwie, ja, ich weiß gar nicht mehr, da ging es so ein bisschen um das Thema Defect-Management.
Und dann habe ich so gedacht, okay, klingt interessant.
Und dann plötzlich tauchst du voll ab.
Und häufig sind das auch gerade so Dinge, die erstmal so von außen her gesehen banal aus, also banal wirken.
aber wo du ganz schnell dann wirklich abtauchen kannst und was sich auch echt viel Zeit kosten kann an der Stelle.
Und 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 selbsterfüllende Prophezeiung auch?
Wenn ich jetzt da reingehe und denke, es dauert, ich brauche eine Woche.
Das ist ja auch diese Scotty-Regel im Prinzip.
Wenn du sagst, ich brauche zwei Wochen dafür und eigentlich Weißt du eigentlich, dass es nicht so lange dauert, aber damit es halt wenigstens so wirkt, das hätte man ein Wunder vollbracht.
Aber das kann natürlich sein, wenn du dich selbst ein bisschen da entweder die zeitlichen Freiheiten lässt oder aber dich selbst in den Druck setzt, dass das durchaus auch Auswirkungen darauf hat, wie lange du wirklich für irgendwas 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 Raumflief Enterprise.
Gab es ein Problem?
Scotty hat gesagt, Ich brauche acht Stunden.
Du hast aber nur vier.
Gut, ich mache zwei.
Genau.
Das war immer der Running Gag.
Unsere Generation.
Sind wir so alt, Ralf?
Wir haben eine ähnliche Bartfarbe.
Stimmt.
Du hast noch volleres Haar oben drauf als ich.
Ja, soll ich es mal abnehmen?
Lass mal.
Ja, also wie gesagt, ja.
Die Lösung eines Problems, würde ich mitgehen.
Jetzt hat hier einer, glaube ich, am Handy getippt.
Meine drei Hauptprinzipien heißt es, glaube ich.
Ist sicher?
Kiss, Dry, Jagni.
Würdest du sagen, das hilft, das Projekt an die Wand zu fahren?
Oder würdest du eher sagen, ach, jetzt gerade...
Ja, don't repeat yourself.
Das ist so eine Sache im Prinzip.
Man lernt doch nur durch Wiederholung.
Ja, also ich glaube, wenn man es exzessiv anwendet, können das durchaus Aspekte sein, die dabei unterstützen, ein Projekt zumindest zu blockieren.
Oder zumindest den Fortschritt ein bisschen aufzuhalten.
Sag mal, 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.
Also auf vielfältige Art und Weise.
Da habe ich auch so einen Punkt, wenn du dein Projekt wirklich sinnvoll an die Wand fahren willst, dann entwickle einfach erstmal schlecht Software.
Wobei ich jedem Entwickler unterstelle, ja, wir alle können, wenn wir wollen, uns anstrengen, können wir schlecht entwickeln.
Also auf jeden Fall.
Und 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, kriegst du ja ganz schnell da, auch 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 Obwuskater, weil es schon Obwuskated ist, oder?
Das ist interessant, weil Pearl war seinerzeit so die erste, also als ich irgendwie Ende der 90er anfing, dachte, boah, ich mache so Online Gaming und ich muss auch nochmal, mein Clan braucht eine Webseite.
Und da habe ich gedacht, boah, dann probiere ich mir mit irgendwas zu schreiben, habe dann so ein Pearl Buch gekauft und das war eine Katastrophe.
Da habe ich gedacht, okay, ich steige jetzt gar nicht in die IT ein.
Ja, aber das ist Pearl.
Es wäre immer interessant hier, ob es eine repräsentative Umfrage gibt, wo steht eigentlich jetzt Pearl überhaupt bei den Sprachen noch?
Müssten wir mal Cloud 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 auch schlimmer irgendwie.
Wenn wir beide zusammenkommen, gibt es relativ viel Smalltalk bedauerlicherweise.
Ja, ja.
Das ist nicht bedauerlich.
Das macht Spaß.
Ich will hier gerade noch einen anderen Kommentar.
Information Hiding, um sich...
Ja, unabkömmlich zu machen.
Ich finde auch so die Komplexität, die hat so ein bisschen, ja, Complexity sells.
Also jemand, der komplexen Code schreibt, ist meistens hoch angesehen, oder?
Weil, wow, der hat das verstanden, der kann das.
Ja, auf jeden Fall.
Es war schwer, dieses Code-Stück zu schreiben.
Es war auch schwer, es zu verstehen.
Also das würde ich auch so ein bisschen in den Themenbereich, wir entwickeln Software eher komplex hin zu, 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.
Das ist der Kommentar schon leider weg.
Ja, das war nochmal zu dem, was du eigentlich gesagt hattest.
War hart zu schreiben, dann soll es auch schwer zu lesen sein.
Das geht nochmal in die Richtung, deswegen hat es gerade eingeblendet.
Ja, 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 in ein paar Wochen noch.
Aber gerade für die Leute, die sich vielleicht das zur Einarbeitung ansehen sollen.
das für die möglichst komplex an der Stelle sein sollte, um auch hier, ja, 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 vor vielen, vielen Jahren.
Als ich da einen Artikel von mir, der beim Java-Magazin veröffentlicht wurde, plötzlich in irgendeiner 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 nochmal und denkst dir zum einen, was wollte ich damit jetzt eigentlich sagen?
Ich glaube, darauf zielt das ja so ein bisschen ab.
Und eigentlich sehe ich das jetzt völlig anders.
Das sind also die beiden interessanten Sachen.
Das wirst du auch an der Stelle haben, wenn du als Entwickler nach einem Jahr nochmal in den Code reinschaust.
Du hast dich ja selber weiterentwickelt.
Oder wenn du angefangen hast, irgendwann mal Architekturdiagramme zu bauen und guckst da nochmal ein, zwei Jahren drauf.
Natürlich, Software ändert sich seitdem.
Man denkt auch, ich würde das jetzt eigentlich komplett anders machen.
Das ist so ein bisschen die menschliche Erfahrung, die da einfach so mit rein, die Entwicklung einfach da mit reinschlägt.
Wollen wir nochmal 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 unerfreuliche Willkommen oder auch das schlechte Dokumentieren.
Wir haben im Grunde jetzt auch schon das Thema technische Schulden so ein bisschen angesprochen.
Auch der unlesbare oder schlechte Code.
Meeting-Kultur.
Ach ja.
Ja, leg mal los.
Meeting-Kultur.
Das ist auch tatsächlich etwas, wo ich ein bisschen lernen musste, hin zu, oder ein bisschen weg davon, einfach so ein Meeting aufzusetzen, Leute einzuladen, keinen Einladungstext.
Das ist schon das Minimalste.
Wenn keiner weiß, warum irgendwo irgendjemand drin ist.
Und wenn du dann wirklich dafür sorgen willst, dass es zu Problemen kommt oder zu Unklarheiten, dann habe 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 den und den Tickets sollen am Ende dieses Meetings geklärt sein, zum Beispiel.
Was häufig aber noch immer passiert in vielen Projekten oder in vielen Umfeldern, am Ende Sitz mal zusammen und denkt, okay, jetzt haben wir hier eine Stunde ein bisschen was geredet.
Die eine oder andere waren die ganze Zeit gemutet.
Ich denke, wir werden uns in einer Woche nochmal hier zusammenfinden und über das Thema weitersprechen.
Und auch dann, du bewegst dich plötzlich in so 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 irgendwie doch merkt, auch ohne Agenda, Ohne Ziel des Meetings hat man irgendwie schon 20 Minuten vor Ende das Ziel erreicht.
Alle sind sich einig.
Und dann sagt man aber doch noch, was machen wir jetzt noch die 20 Minuten?
Über was diskutieren wir noch?
Es ist nicht immer spannend, wenn man eben versucht, den Raum zu füllen.
Auch das gibt es.
Statt es einfach mal zu lassen.
Was dazu passt, du planst Meetings, denkst du, wir brauchen ganz viel Zeit, ich plane mal zwei Stunden ein für zwei, drei Agenda-Punkte.
Und dann bist du, wenn du dann nach 20 Minuten fertig bist, hat er immer so viel Zeit.
Action Point, Follow-Up-Meeting, ja genau.
Ja, eben, das erlebt man so häufig.
Geht in die richtige Richtung.
Ja, und man muss sich ja im Grunde auch immer dann vorstellen, je mehr Meetings stattfindest, so schlechter ist die Qualität des Poirier auch.
Auch gut.
Das zugrunde liegende Problem ist ja immer, du bindest einen ganzen Haufen Menschen für eine gewisse Zeit X.
Und es wird sich häufig, zwei Dinge werden sich nicht überlegt.
Müssen diese ganzen Menschen mit dabei sein?
Also, 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, okay, kann ich als Person, die eingeladen ist, eigentlich sinnvoll was dazu beitragen?
Also das finde ich auch so ein bisschen...
so die Extreme, weil man tendiert häufig auch dazu, einfach mal die große Runde und plötzlich hast du 20 Leute drin sitzen, aber nur drei diskutieren, der Rest hört zu.
Das ist, glaube ich, auch nicht zielführend, aber man kann natürlich einen netten Kaffee dabei trinken.
Oder man schickt das in irgendwelche Gruppenpostfächer, dann wird es weitergeleitet und eigentlich hat man gedacht, man hätte nur drei, vier Leute da sitzen und dann plötzlich explodiert der Teilnehmerkreis an der Stelle und plötzlich hast du Leute drin, die du eigentlich gar nicht drin haben wolltest vielleicht.
Da muss man so ein bisschen mit Fingerspitzengefühl wahrscheinlich rangehen, zu überlegen, okay, 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 Stühle 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.
Das ist ein bisschen Katastrophentourismus.
Ursprünglich hat man ja mal die agilen Stand-Ups, Stand-Up 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.
Ja, das ist glaube ich auch so ein Aspekt, der durch die Remote-Arbeit ein bisschen verloren gegangen ist.
Also wahrscheinlich hat nicht jeder zu Hause einen Tisch zum Hochfahren, um sich hinzustellen.
Das musste man mal so 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.
Noch ein Kommentar.
Also ich finde auch, dass sich Entwickler oft schlecht auf Meetings vorbereiten.
Sie hassen Meetings einfach, weil sie 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 und weil sie lieber programmieren.
Ich hatte mal so eine Situation, wo mich ein Projektmanager als Techie in jedes Meeting mit reingenommen hat und in jedem Meeting ich so, das müssen wir machen, jenes müssen wir machen und sonst was.
Und am Freitag, nachdem ich die ganzen Tage mit Meetings verbracht habe, hat er mich dann gefragt, Wo stehen wir denn jetzt?
Und ich habe so nachgedacht und habe gemeint, du hast schon gemerkt, dass du mich den ganzen Tag, die ganze Woche in Meetings reingezogen hast und wo hätte ich irgendwie was umsetzen können.
Und 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 eben Aufgaben mitnimmt.
Bin ich so als Techie nicht gewöhnt?
Okay, das können wir so stehen lassen.
Ja, also, ja, ja, ja, das ist ein interessanter Aspekt.
Man kann auch in Meetings reingehen, ohne direkt Aufgaben mitzunehmen.
Naja, also wenn ich zum Beispiel nur moderiere, ja, ja, und vielleicht im Meeting noch verteile.
Ich finde das 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.
Was ich da sagen muss, der Sweet Spot dazwischen sein.
Ich meine, klar, es gibt unterschiedliche Rollen in Projekten.
Die einen Rollen, die 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 drüber unterhalten, wie man diese gestalten möchte.
Wenn man es nicht macht, dann kann es auch schnell passieren, boah, ich habe den ganzen Tag noch Meetings, boah, da habe ich ja gar keine Lust drauf.
Motivation sinkt, Produktivität sinkt und wir schaffen es auf jeden Fall, vielleicht unter die 19 Prozent zu kommen.
Sweetbot, da sagst du jetzt gerade was, weil Und wahrscheinlich kann man ja auch ein Projekt gefährden, indem man die Teams zu groß stufft, oder?
Umso größer, umso mehr Kommunikation.
Ja, 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 man 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, da sich selbst organisierte Teilteams zu bilden.
Kann mal funktionieren, muss nicht.
Ja, kann funktionieren, muss nicht.
Jetzt haben wir viel drüber geredet, wie man es nicht machen sollte.
Und 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.
Das ist das Erste.
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 dran ä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 drüber zu sprechen, es ins Gespräch zu gehen.
Ja, unsere Meetings, die haben keine Agenda, das kostet uns eine Zeit und bringt uns nichts.
Vielleicht muss es mal jemand aussprechen.
Auch wenn es offensichtlich ist.
Man sich wundert, warum es keiner getan hat.
Manche trauen sich nicht, weil sie vielleicht auch denken, oh Gott, ich bin nicht jeder 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, oh, 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, jetzt den Putsch zu starten und da irgendwie 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 Pain-Point-Liste.
Beschreibe genau das, was das Problem ist.
Beschreibe, was löst dieses Problem A.
Also wozu führt dieses Problem?
Was weiß ich.
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 Meetingstruktur ist, wie eine Falsagenda einführt.
Ich finde das mit den Meetings eigentlich ein schönes Beispiel, weil ich glaube, das kennt fast jeder.
Das wirklich mal aufzuzeigen, auch wirklich verschriftlichen die Dinge, auch komponizieren.
Nicht mal nur sagen, ja, 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 Meeting-Agenda, theoretisch sollte jeder wissen, dass die mitgeschickt wird.
Praktisch sieht man die verdammt selten.
Da hat man sich vor drei Wochen mal kurz abgesprochen, komm, ich stelle uns ein Meeting ein.
Und das ist dann doch ohne Agenda, weil man hat sich ja 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 da wieder, dann kommst du wieder in diese Denke rein, aber woanders hat es funktioniert, dann übernehme das so einfach mal hier.
Also es ist ja auch da mal so ein bisschen so eine kritische Hinterfragung.
Passt das wirklich?
Sag mal, jetzt sprechen wir hier von was Organisatorischem, wenn es um was 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-Umfeld mit Spikes oder sonstigen Geschichten, dass man Dinge ausprobieren, aber nicht einfach ungeprüft komplett übernehmen.
Kann in Maßen sein.
Da sind wir 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.
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 irgendwie aus der Zeit rauslaufen, der eine Gedanke dazu, wir im Endeffekt wirklich ausprobieren, überprüfungsfunktionieren, also das ganz klassische Inspector Debt kennen ja die meisten irgendwo.
Das letzte im Prinzip, manchmal gibt es halt Dinge, die wir nicht ändern können.
Manchmal existiert es immer, aber vielleicht, wenn wir fünf, sechs Flächenbrände haben, kann es vielleicht auch manchmal 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.
Wenn das jetzt zu unstrukturiert war, dass wir hier einfach so drauf 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, 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.
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.
www.software-architektur.tv Sei dabei, stell Fragen und komm auch gerne auf uns zu.