Transkript: Projektmanagement - "es ist alles nicht so einfach"

Ja, hallo liebe Hörerinnen und Hörer, willkommen beim Python Podcast, Folge 22.

Wir machen heute Projektmanagement, vielleicht auch ein bisschen mit Python.

Und spannenderweise ist genau diese Folge die Folge, die bis jetzt am wenigsten funktioniert hat und wir versuchen seit September diese Folge aufzunehmen und hatten schon mehrere Termine, die dann wieder geplatzt sind und dann haben wir schon mal eine Folge aufgenommen, die total nicht funktioniert hat und jetzt fangen wir wieder von vorne an.

Also Projektmanagement ist eine tricky Sache.

Wir sind wieder beim Jochen im Wintergarten.

Hallo Jochen.

Und Remote

und Remote dabei sind heute wieder zwei unserer Stargäste.

Und zwar der Christian und der Johannes.

Hi.

Hallo.

Oh, hallihallo.

Ja.

Vielleicht noch ein bisschen vorher am Anfang ein paar News aus der Szene einstreuen.

Ja, können wir eigentlich mal mit anfangen.

Genau.

Ja.

Was gibt's denn Neues?

Der Christian hatte was Spannendes, glaube ich.

Ich hatte eingeworfen, wart ihr eigentlich nicht beim Python Camp dabei?

Ich habe gerade überlegt, wie gesagt, da hatte ich das vorgestellt, weil ihr sagt jetzt, dass sie es Pip-Env gerade in eine Release bekommen hat, zum Thema, wie man so Anwendungen pakettiert, beziehungsweise ganze Anwendungen irgendwo ausrollt mit dem Virtual Env.

Da habe ich tatsächlich Anfang des Jahres oder vor so zwei, drei Monaten, als Corona gerade losging, selber was gebaut.

Das nennt sich App-Env, womit man dann mit einer Requirements-Textdatei oder einer Freeze-File in der Lage ist, so Self-Contained, Self-Bootstrapping-Anwendungen zu bauen, die man aber auch auf beliebige andere Python-Pakete einfach draufjagen kann.

Genau, das war so ein kleines, interessantes Werkzeug für Leute, die in dem großen Podpourie aus wie kann man noch Virtual Entschuldigung da reinzuhören.

Eine der wenigen Möglichkeiten, Virtual Envs zu machen.

Ja, was sind eure Lieblingssache?

Also das ist tatsächlich auch dein Lieblingsweg, da Enf zu machen.

App Env.

Halt immer für dieses Thema von, ich will die in der Form vorliegen haben, um in Projekten, wo ich mich mit anderen koordinieren muss, und wir das nicht so global auf dem System installieren wollen, ist es bei AppEnv so, dass du so eine kleine Bootstrap-Datei unter dem Namen, wie du diese Anwendung in dem Projekt benutzt, in deine Repository mit eincheckst, sodass jeder andere, der dieses Projekt auscheckt, einfach nur Punkt slash, in unserem Fall ist das Bateau, das Deployment-Werkzeug, aber das kann halt irgendwas anderes sein, was dann in einem Virtual

Env als Executable lebt, aufgerufen wird und er sich automatisch darum kümmert, dass jeder die richtige Version und alle Dependencies etc.

bekommt.

Und wenn du halt manchmal im Team mit 20, 30 Projekten arbeitest, die alle unterschiedliche Versionen haben und aber dann eins wurde dann doch wieder aktualisiert, dann ist das halt eine schöne Variante, um zu machen, dass niemand sich darum kümmern muss, wenn er mit dem Ding interagiert, ob das jetzt gerade aktualisiert wurde oder nicht.

Insofern, das passt uns sehr, sehr gut, ja.

Ja, okay.

Für eine Entwicklung nehme ich es aber nicht, also für wenn ich Projekte entwickle, dann mache ich meistens einfach wirklich bloß ein ganz dummes Virtual Ents in einem ausgecheckten Repot rein.

Ich mache gern viele tausend Virtual Ents überall rechts und links.

Ich activate die auch nicht, sondern ich rufe die dann immer mit den absoluten Faden aus dem Projekt raus auf.

Okay.

Ich habe mich so ein bisschen in das, was Joch mir gezeigt hat, Poetry verliebt.

Das fand ich irgendwie auch ganz nett.

Ja, also ich benutze meistens Poetry und das ist halt auch, also in den Projekten, ich habe es noch nicht alles umgestellt, aber in denen, in denen ich das getan habe, war es dann halt auch so, dass es relativ einfach ist.

Immer wenn ich jetzt da irgendwie was ändere, los mache ich gleich ein Poetry-Update und sozusagen habe dann auch immer aktualisierte Fassungen, während das bei dem Ansatz, den ich früher hatte mit Virtual Ends immer so ein bisschen hakelig war.

Das muss man sich erst raussuchen, welche sind denn outdated und kann man die jetzt upgraden oder nicht.

Aber Poetry-Update einmal Tests durchlaufen lassen.

Reicht eigentlich immer und das funktioniert tatsächlich auch für mich ziemlich gut.

Was mich so ein bisschen nervt, ist, dass es teilweise sehr, sehr lange braucht, bis die Dependencies aufgelöst sind.

Ich weiß nicht so genau, woran das liegt.

Aber was halt da interessant ist, ist jetzt, es gab tatsächlich eine neue Pip-End-Release irgendwie.

Ja, und da sind einige interessante Geschichten dazu gekommen.

Das heißt also, momentan könnte man sich das nochmal angucken.

Und vielleicht wäre jetzt nochmal ein guter Zeitpunkt, das mit Poetry zu vergleichen, weil Poetry habe ich eigentlich nur deswegen genommen und dann halt auch vorgeschlagen, weil das halt aktiv entwickelt wurde.

Und PipEnf sah so ein bisschen danach aus, als wäre die Entwicklung da im Wesentlichen schon passiert und das liegt halt so rum, aber tut irgendwie nichts mehr.

Und das hat sich wohl geändert.

Also insofern sollte man sich das vielleicht nochmal angucken, aber habe ich jetzt auch noch nicht gemacht, insofern kann ich dazu nichts sagen.

Ja, bei Pip-Enf stand halt so ein bisschen raus, dass da auch mal wieder so einen Übergang gab von, ich glaube, war das Kenneth Waits, der das Original entwickelt hatte.

Und er dann halt aber auch in einer Form hatte, wo er sagte, so ja, ganz fertig ist noch nicht und dann der Übergang zu die Pipe PR-Leute haben gesagt, wir würden sie eigentlich im Prinzip jetzt übernehmen, aber diese Arten von Transitionen sind halt mit Kenneth manchmal so ein bisschen holperig.

Ich merke auch gerade, ich habe gerade

Der Kenneth ist auch so einer, der gerne Projekte anfängt, oder?

Der macht ganz viele Sachen erstmal und die ja, da gibt es ganz viele Sachen, die er mal angefangen hat, um es mal so zu sagen.

Es ist keine Kritik oder so, sondern es ist einfach was, um die Überleitung hinzukriegen.

Wenn wir keine News mehr gehabt hätten.

Erfolgreiche Projekte werden auch irgendwann beendet und so.

Was unterscheidet denn irgendwie so ein Stück Software von einem Projekt?

Ja, das ist ja eine interessante Frage.

Ja, was ist das?

Wenn ich seine News habt, müssen wir da mal drüber sprechen.

Ja, ja.

Ach du, du hattest auch noch recht.

Ja, ja, natürlich.

Ja, jetzt breake ich ja wieder einfach so rein und mache trotzdem wieder News.

Und zwar gab es einen Blog-Eintrag von Kel Patterson, der geschrieben hat, dass Aseng Python nicht Faster ist und da ein paar Benchmarks gemacht hat.

War ganz interessant.

Dann werden wir mal in die Shownotes linken.

Oh ja, da gab es dann auf Twitter, habe ich nur gesehen, dass das irgendwie Leute, die darauf reagiert haben und dann geschrieben haben, ah, das war alles Unsinn.

Aber ich weiß nicht mehr genau, warum oder wer oder das bin auch noch so hard dran?

Ja, ja.

Schneller als schneller als Async ist die Aussage von diesem Blogpost.

Ja, aber für was?

Ja, genau, ich kann mal einen Benchmark schreiben, der beliebige Ergebnisse hat.

Gute Frage für was?

Ja, er hat die verschiedenen Web-Server getestet unter verschiedenen Loads, je nachdem wie viel Work an und wie viel Throughput hast du irgendwie generiert.

Also was ich einfach um auch ein bisschen mitzuweinen, was ich dann auf Twitter gelesen habe, ist, dass die Leute ihm vorgeworfen haben, dass er halt eigentlich nur Postgres getestet hat, weil da war halt irgendwann Schluss und ja, er hat halt irgendwie gar nicht wirklich Async getestet und das wäre halt irgendwie nicht okay gewesen, der Benchmark.

Aber ich habe es mir auch selber nicht angeguckt, insofern kann ich natürlich nicht sagen.

Aber das ist auf jeden Fall eine interessante Geschichte.

Ich würde auch sagen, also was die, ich meine, das ist halt, das ist ein schwieriges Thema.

Leute wissen nicht so genau, was sie meinen, wenn sie denn sagen, Async ist schneller.

Also insofern, ich meine, ich würde auch sagen, also wenn man Async irgendwie macht, hat das natürlich einen gewissen Overhead.

Also wenn man jetzt einfach nur ein Programm hat, das irgendwie durchläuft, dann ist das in der Sync-Fassung immer ein kleines bisschen schneller als in der Async-Fassung.

Aber wenn man jetzt irgendwie, keine Ahnung, viele Requests gleichzeitig beantworten will oder so, oder dann kann das natürlich mit Async deutlich schneller sein.

Es kommt halt immer drauf an, was man macht.

Also was man misst, also misst man die Zeit von, es fängt an, Requests zu bearbeiten, bis der Request ist, fertig bearbeitet, oder wie viele Requests pro Sekunde gehen da durch oder so.

Was misst man da eigentlich?

Wichtiger finde ich eigentlich eher, es geht ja darum, dass das ein anderes Programmierparadigma ist, in dem man bestimmte komplexe Abläufe halt zuverlässiger aufschreiben können soll.

Also du hast halt manchmal das Problem, dass du irgendeine Form von Parallelisierung brauchst, Parallelisierung Richtung I.O., Parallelisierung im Balancing, wer irgendwie Compute-Zeit kriegt und Async ist ja tatsächlich halt, heißt ja erstmal Async.io.

Und da halt Patterns zu haben, die dann zum Beispiel eben schneller und skalierbarer auf irgendwie viele Endpoints reagieren können.

Das sind ja die Themen, wo dann im Linux oder bei anderen halt das Thema Select-Poll, E-Poll etc.

kommen, um zu gucken, wie viel CPU-Overhead muss eigentlich nachher drauf gehen, um diese ganzen ausstehenden Ressourcen zu verwalten, damit dann irgendwann wieder aus der Kernel-CPU-Zeit in die System-D User-CPU-Zeit gewechselt werden kann, um zu sagen, ah, ich habe ja jetzt, du kannst jetzt wieder richtige Arbeit machen, ich stehe jetzt nicht bloß da und drehdäumchen, um rauszufinden, wo was erreicht wurde.

Und das kannst du mit Threads natürlich auch machen, hast aber da dann wiederum halt das Problem, dass das ganz schnell in Locking-Probleme und Koordinationsprobleme und gescherte Datenstrukturen und A-Sync hat halt dort den Vorteil, du kannst es leichter aufschreiben, weil die Punkte, wann die Kontrollflüsse unterbrochen werden, besser kontrollierbar sind.

Weil du halt weißt, immer nur, wenn ich healte oder die, wenn ich die Methode verlasse, die Coroutine verlasse, dann gibt es diese Kontextwechsel.

Das heißt, du brauchst an vielen Stellen bei geteilten Datenstrukturen keine Loks, etc.

etc.

etc.

Das ist halt.

Ah, okay, aber das ist interessant.

Ja, nee, das finde ich völlig valide und ich meine, ich würde jetzt sagen, mit Threads kann man das ja auch irgendwie, sozusagen dann nimmt man halt eine Que und Loks, gut, ja, eben, stimmt, braucht man also ein Kinder-System.

Genau, Loks haben halt das Problem, das sind Kernel-Datenstrukturen, die du fürs Locking halt brauchst und die haben halt Overhead und es ist halt blöd, und wenn du die gar nicht mehr brauchst, zack, geht das halt weg.

Deswegen ist eher die Frage, wie verhält sich Async-IO gegenüber Threads?

Und für mich die wichtigere Kombination ist aber, dass du halt Fehlerquellen eliminierst.

Das Dumme ist halt, Async ist jetzt auch nicht perfekt und es programmiert sich manchmal auch ein bisschen komisch, das ist halt so dieses Rot-Blau-Problem, dass es dann halt plötzlich in deinem Python-Code hat halt dann eine rote und eine blaue Variante, nämlich die Funktionen, die sync sind und die Funktion, die async sind und die darfst du nicht durcheinander bringen.

Die dürfen sich auch nicht gegenseitig aufrufen, ist auch eine super

coole Sache.

Ja, genau, da musst du immer so immer so eine Übergabe-Punkte machen.

Und das ist tatsächlich so ein bisschen, na, es geht noch fluffiger.

Ja, es ist noch optimaler.

Ja, alles Async.

Das ist die Lösung, die jetzt gerade in

Deutschland ist.

Furchtbar.

Nee, nee, also ich mache das tatsächlich eher so, dass ich dann immer mal so Codezweige habe, wo ich sage, jetzt muss ich parallel was machen, jetzt hole ich mal für diesen Subcall-Tree A-Sync raus, dann kommt dieser ganze Kram in A-Sync und danach geht es wieder zurück.

Ja, finde ich sehr interessant, weil ich hätte jetzt so spontan gesagt, wenn ich, wenn mich jemand gefragt hat, was der Unterschied oder wo ich den Unterschied sehen würde zwischen Threads und Async, dann würde ich auch sagen, ja, also Threads ist halt im Grunde macht das genau das gleiche.

Es ist beides Multiplexen von I.O.

irgendwie Parallelität und aber Threads gehen halt nur beschränkt viele, weil, naja, das sind halt auch wieder Kernel-Datenstrukturen und du hast halt pro Thread irgendwie ein gewisses Maß, was man da dann halt irgendwie anlegen muss.

Und wenn man dann halt nach ein paar hundert, paar tausend ist dann halt irgendwie einfach Schluss.

Während ich mit Async.io halt auch, weiß ich nicht, halbe Millionen offene Verbindungen gleichzeitig haben kann.

Weiß ich nicht, ob es man es wirklich haben kann, aber so theoretisch könnte es sein, dass es geht.

Und ja, das ist halt auch quasi vergleichbar schnell.

Insofern kann man dann für solche Sachen, wo man ganz, ganz viele Verbindungen hat, dann halt irgendwie Async-IO annehmen als Threads, aber ansonsten, ja.

Und Threads sind halt hässlich zu debuggen, aber das ist Async.io möglicherweise halt auch irgendwie, da habe ich jetzt noch gar nicht so viel Erfahrung mit.

Ja, die Adword ist, ja.

Also da gibt es halt auch, ich meine, es gibt ja andere Sprachwelten, halt gerade JavaScript, Node.js.

JavaScript hat von der Sprache halt her schon ein besseres Execution-Modell, was die Vorhersagbarkeit angeht, wann du die Kontrolle über deinen, über die Ausführungen verlierst.

Bei Python Threading kannst du halt bei jedem State, bei jedem Bytecode-Statement kann es halt sein, dass die Kontrolle wechselt.

Und dann weißt du halt teilweise noch nicht mal, ob die eine Zeile, die gerade ausgeführt wird, komplett durchkommt.

Oder ob du zum Beispiel beim Assignment rechts die Expression noch ausgeführt kriegst, dann kommt irgendein anderer Thread und beim Assignment auf das Target hat sich schon irgendwas geändert.

Und bei Async und bei JavaScript ist es halt eben so, du weißt, erst wenn du den Execution-Block über einen Yield oder über einen Coroutine-Call oder halt den Call verlassen, erst wenn du den verlässt, dann geht die Kontrolle weg und solange kannst du dich darauf verlassen, dass niemand in diese Liste reingeschrieben hat, niemand irgendwie Dinge getan hat.

Und das reduziert den Denkaufwand schon nochmal ganz schön massiv.

Was man häufiger machen muss, ist, man muss, glaube ich, den Code nochmal anders strukturieren, dass er irgendwie lesbar ist, um ihn für Menschen wieder serialisiert irgendwie durchgucken zu können.

Das ist auch das, was man halt kennt in der Python-Welt dann wieder von dem Twisted.

Das Zeug heißt halt nicht umsonst so.

Das Twisted-Modell ist sehr, sehr nah an dem dran, was Async-Eye im Prinzip macht, mit The Promises und so einem Zeug.

Und am Ende hast du halt für etwas, was du seriell sync, einfach nur A, B, C, D, E runterschreiben würdest, plötzlich 40 Funktionen gefühlt, die sich alle gegenseitig mit irgendwelchen Promises und Callbacks und wenn der den aber mit Error Handler da drüben und wenn der Error Handler von dem aufgeht und da blickt man halt sehr schnell nicht mehr durch.

Und das hat da halt eine Balance zu finden, da müssen sich jetzt alle auch erstmal irgendwie dran gewöhnen.

Das gibt es in JavaScript jetzt übrigens auch, Clements auch Promises.

Also man kann auch in JavaScript jetzt.

Mag jemand mal ganz kurz erklären, was eine Promise denn überhaupt ist?

Ich weiß nicht, ob das jetzt super gut in die Projektmanagement-Folge reinpasst, aber ein Promise.

Ein Promise ist eine Berechnung, die zu einem späteren Zeitpunkt erst fertig werden kann.

Das heißt, anstatt dass ich sage, das Ergebnis ist 5, sage ich, ich verspreche dir, dass wenn du das Ergebnis abrufen willst, dann mache ich es auch fertig.

Das heißt, das Promise ist so eine Verpackung für irgendwann wird ein Ergebnis hier sein.

Und die Garantie, dass das Ergebnis vorhanden ist, ist erst da, wenn das Promise abgerufen wird.

Und die Hoffnung ist halt, dass man in der Zwischenzeit so genügend andere Dinge gemacht hat, dass das Promise quasi in Null Zeit berechnet werden kann.

Weil zwischendurch immer mal wieder eine von den asynchronen Co-Routinen daran arbeitet, dass das ein bisschen weiter verpackt wird.

Ja.

Also das ist auch eine Verallgemeinerung, die, was man von Threads kennt.

Also Threads kannst du halt ja auch sagen, du kannst halt zwei Varianten benutzen.

Du kannst halt entweder sagen, du machst ja ein Thread-Pool, wo eine Funktion immer wieder irgendwas abrufst und verarbeitet und dein Thread läuft unendlich lange, oder du startest bestimmte Funktionen mit Parametern in einem Thread und kannst den dann joinen.

Kannst halt dann, das heißt, in deinem Hauptprogramm kannst du irgendwie sieben Dinge anfangen, kriegst dann die Thread-Objekte und kannst am Ende sagen, so Join, Join, Join, Join.

Und das Join wird in deinem Haupt-Thread wieder returnen, in dem Moment, wo der Thread sagt, so ich habe mich beendet.

Und eine Future oder halt eine Promise ist im Prinzip die Abstraktion davon, dass du irgendwelche Calls hast, die so ein Future-Objekt liefern, und dann hast du auf dem Ding halt eine verallgemeinerte Möglichkeit, um zu sagen, also übrigens, falls das schief gehen sollte, hier ist noch ein Callback, der bitte aufgerufen werden sollte, wenn es schief gehen sollte, hier ist noch ein Callback, der aufgerufen werden sollte, wenn es erfolgreich ist.

Und sag mal, wie geht's dir eigentlich gerade?

Das ist sozusagen diese Verallgemeinerung von diesen Patterns von, ich lasse irgendwas asynchron ausführen und will dann irgendwann sagen, so, jetzt hätte ich es gerne, jetzt warte ich drauf, dass du fertig wirst.

Okay.

Man kann aber auch in JavaScript inzwischen irgendwie Async-Await-Syntax, die praktisch genauso aussieht wie in Python verwenden.

Insofern.

Aber da kommt es dann sehr drauf an, welche Bibliothekwelt man gerade lebt, was die Promises macht.

Oder Futures oder Await oder Threads oder Timeout oder Callbacks.

Und was man halt tatsächlich dann nicht vergessen darf, ich erlebe das immer wieder, wenn ich Projekte habe, wo Node.js eine Rolle spielt, man muss in den Async-Sachen dieses ganze Thema Kontrollflusssteuerung mit Exceptions ganz anders handhaben.

Und mein Liebling, der mir bei Node immer auffällt, und das passiert immer in Python aber halt auch, ist, wenn dann irgendwelche Datenbanken angesprochen werden und der Datenbank-Server geht mal kurz weg und du kriegst dann halt mittendrin irgendeine Exception von, ja, hier war die Connection weg, und niemand hat im Framework ordentlich Händler für diese Exceptions registriert, dann sitzt dein, weil dein Hauptthread macht später nichts anderes mehr, als nur diesen Loop von, ja, gibt es hier noch Async-Dinge zu tun, ja, dann husche, husch, ah, hier sind wieder neue, husche, hush

Und der beendet sich aber nie.

Und wenn aber dann halt sozusagen die ganzen Libraries alle mal gestorben sind und nur noch sagen, ja, ich konnte mich ja nicht connecten und mein Connection-Pool ist weg und keiner behandelt diese Exceptions, dann sitzt dein Programm da rum, tut so, als wenn alles okay wäre und das Monitoring sagt, läuft doch.

Wir haben heute erstaunlich wenig Last auf unserem Request.

Ja genau, aber tatsächlich häufig ist es so, der Webserver in dem Ding antwortet dann für irgendwelche Statusseiten immer noch, ja, ich bin anwesend, dass aber die realen Requests alle auf die Schnauze fliegen und er zu doof ist, sich zu reconnecten.

Und das ist was, das hättest du in einem seriellen Ding oder einem synchronen Ding eher weniger.

Da würde diese Exception normalerweise bis in den Main-Loop durchbabbeln und dann explodieren.

Und dann geht die Anwendung aus, wird neu gestartet, kann sich zur Datenbank reconnecten und dann ist alles gut.

Das sind sozusagen Sachen, da hat man jetzt sozusagen Probleme, die eigentlich schon mal auf eine andere Art gelöst waren.

Die hat man sich jetzt nochmal eingefangen, die muss man jetzt mit ordentlichem Handwerkzeug neu machen.

Aber ordentliches Handwerkszeug, ich will jetzt nicht zu sehr über die JavaScript-Welt herzählen.

Aber das ist ja in Python genauso.

Also ich meine, die Sachen könnten ja auch in Python abspringen.

Aber da kann man jetzt vielleicht nochmal einen Übersprung zum, außer der Dominik hat noch mehr News.

Können wir nochmal einmal sagen,

Wackman kommt.

Weil dieses ordentliche Handwerkszeug ist ja durchaus sowas, was man versucht, über Projektmanagement in den Griff zu kriegen.

Ja, dass man halt sagt, okay, bevor jemand irgendwas hier in den Master Branch pushen darf, müssen alle Tests gelaufen sein oder irgendwie sowas.

Dass du halt das über quasi Prozesse in den Griff kriegst, die nicht in der Software drin sind, sondern in den Menschen.

Jetzt könnte ich dazu ja gerade mal so die auf meinem Stichwortzettel für heute, ich wollte so diese Antithese gerade, ich wollte mit dem bösen Onkel, aber ich fürchte, ich bin zu nah an dem dran, was du gerade tatsächlich aussagen wolltest.

Also ich beobachte Projektmanagement in den letzten Jahren häufig als eine Art Form von industrialisierter, weaponized Möglichkeit, um Entwickler möglichst zügig in einen Zwei-Wochen-Rhythmus durch eine Ticketliste zu prügeln.

Da bist du aber tatsächlich mit.

Würdest du sagen, es funktioniert oder würdest du sagen, es funktioniert nicht?

Das funktioniert halt in den Fällen, wo die Leute nichts Neues machen müssen, sondern halt tatsächlich einfach bloß das Zeug abarbeiten, was sie immer machen.

Ja, aber da würde ich sagen, das ist natürlich dann eigentlich.

Das ist eigentlich nur Bearbeiten von Tickets, dann schätzt euch ja hin und Ticket, Ticket, Ticket, Ticket, Ticket, Ticket, Ticket, Ticket.

Das ist ja auch eine Art von Projektmanagement.

Also die Priorisierung dann, welches Ticket du nimmst oder machst du die Reihenfolge nach oder waren die auch eine First In, First A.

Was ist denn ein Projektmanagement vielleicht?

Fangen wir da nochmal ganz von vorne mit an.

Was ist ein Projekt?

Da haben wir uns doch letztes Mal schon drüber gestritten.

Ja, das letzte Mal haben wir aber wieder weggeschmissen.

Das musst du nochmal darüber einfachen.

Schmeiß mal einfach die gleichen Personen über das gleiche Ding und hoffen, dass es jetzt die Debatte

umgeht, dass wir heute was anderes sagen.

Also, also ich kenne die Definition von Projekt so, dass es ein Vorhaben ist, was zeitlich begrenzt ist und ein genau definiertes Ziel hat.

Das heißt, das Projekt wäre irgendwas, genau, ganz harte Regeln.

Beziehungsweise genau definiertes Ziel kann ja auch sein, wir wollen besser werden.

Das ist ja auch ein genau definiertes Ziel.

Das Wichtige ist wirklich, es muss einen zeitlich festgelegten Rahmen haben.

Das heißt, es muss von einem Zeitpunkt bis zu einem Zeitpunkt gehen und es muss ein Ziel haben.

Und idealerweise ist das Ziel so definiert, dass du hinterher sagen kannst, ja, das Projekt war erfolgreich oder das Projekt war nicht erfolgreich oder es war teilweise erfolgreich.

Das ist ja schon sehr konkret.

Also es ist nicht einfach Arbeit, die zu tun ist.

Genau, es ist nicht einfach Arbeit, die zu tun ist, sondern es ist ein Ziel.

Du willst ein Ziel erreichen.

Das Ziel kann natürlich sein, Arbeit ist fertig.

Der Zeitraum ist zwei Wochen und in zwei Wochen sind folgende Tickets abgearbeitet.

Das ist ja auch ein Ziel, ja.

Das ist auch ein Projekt in dem Sinne.

Naja, aber welche Dimension hat denn jetzt zum Beispiel so ein Ziel?

Ich kann jetzt ja ganz viele kleinteilige Ziele machen und die unter einem großen Oberziel und ganz vielen großeren mehreren Zielen machen.

Ab wann fängt da ein Projekt an?

Ja, das ist jetzt das, was Projektmanagement ist.

Das Projektmanagement, wie du deine Projekte managst, sagt im Wesentlichen, wie lange deine Projekte sind und wie groß die Ziele sind.

Du kannst natürlich ein Projekt machen, das heißt Firma und das.

Projekt Weltherrschaft.

Das Projekt heißt Geschäftsjahr und das Ziel ist es, am Ende des Geschäftsjahres viel Umsatz gemacht zu haben.

Profit, Profit, wir trieben nach Profit.

Genau, sagst

einfach Profit.

Wir wollen am Ende des Geschäftsjahres Profit machen.

Und das ist super gut, ja, weil du weißt ganz genau, es geht vom 01.01.

bis zum 31.12.

und dann guckst du am 31.12.

auf dein Dashboard und siehst, wie viel Profit du gemacht hast.

Und das ist super gut messbar.

Aber es ist für die Ausführung, für die Durchführung des Projektes vielleicht nicht so gut, weil da nicht drin steht, weil da nicht da dran hängt, was du tun kannst.

Und das ist sozusagen das größte Projekt, was du machen kannst.

Ich will über die längste Zeit, die ich mir denken kann, möglichst viel Gewinn machen.

Und das kleinste Projekt, was du machen kannst, ist, ich ein Meeting.

Du gehst in ein Meeting und sagst, das Meeting dauert von neun bis zehn und das Ziel ist es, wir müssen entscheiden, ob wir JavaScript oder Python verwenden.

Und das wäre auch ein Projekt.

Wenn du das möchtest, kannst du das auch als Projekt sehen, ja.

Weil das ist ein zeitlich begrenztes Vorhaben, was ein definiertes Ziel hat.

Die Frage ist, wie sinnvoll ist das?

Ist es jetzt sinnvoller, eine Million Projekte zu haben, die so klein sind, oder ist es sinnvoller, ein Projekt zu haben, was sehr groß ist?

Und die kann man denn in der Mitte liegen?

Kann man denn ganz viele kleine Sachen managen oder braucht man was ganz Großes managen?

Was ist denn da am Managen?

Was heißt das?

Strukturiere ich das um, priorisiere ich das, mache ich eine große Liste, wann was gemacht werden muss?

Versuche ich alle Menschen bei Laune zu halten, um zu gucken, dass die einfach arbeiten, was ist.

Ja, alles, was du sagst, würde ich sagen.

Also alles, was du tun musst, um deine Ziele zu erreichen.

Was ich halt spannend finde, ich habe gerade nebenbei noch die Wikipedia offen gehabt und ich habe festgestellt, es gibt eine Dean für den Begriff Projekt.

Sehr schön.

Es gibt eine Dean für alles.

Es gibt die DIAN 69901, die sagt, ein Projekt ist ein Vorhaben, das im Wesentlichen durch die Einmaligkeit, aber auch Konstante der Bedingungen in ihre Gesamtheit gekennzeichnet ist, wie zum Beispiel Zielvorhergabe, zeitliche, finanzielle, personelle andere Begrenzungen, Abgrenzung über andere Vorhaben und die projektspezifische Organisation.

Also was ich interessant finde an der Schaus, ist tatsächlich dieses Thema Einmaligkeit und Zielgerichtetheit.

Und wenn ich an der Stelle jetzt darüber nachdenke, das gilt halt für viele Dinge, die ich so sehe.

Wenn man jetzt mal fragt, okay, was tun wir eigentlich den ganzen Tag lang, dann gilt es halt fast gar nicht mehr so.

Also zeitliche Abgegrenztheit, also ich finde zum Beispiel jetzt diese Metapher mit das Geschäftsjahr einer Firma, das ist so ein bisschen sehr synthetisch und sehr, sehr hergeholt.

Ja, klar.

Weil tatsächlich so diese Einmaligkeit und zeitliche Begrenztheit ja eigentlich nicht gegeben ist.

Die ist ja nicht aus diesem Zweck selber raus.

Und wenn man halt Organisationstheorie anguckt, sollte ein Unternehmen im Prinzip tatsächlich auch erstmal noch andere Funktionen haben als nur die Erwirtschaftung des Profits.

Natürlich, das war das beide

gesagt für die größte Einheit, die man sich denken kann.

Ja, ja.

Und ich finde es aber spannend, weil nämlich dieses Thema Einmaligkeit und Zielgerichtetheit heutzutage in vielen Aufgaben, die vor einem liegen, gar nicht mehr so gegeben sind.

Oder halt dieses Thema konstante Ressourcenallokation, solche Dinge.

Für mich ist das was ganz anders.

Das ist voll witzig, dass du genau diese beiden Begriffe rauspickst, weil für mich ist der zeitliche Aspekt einer, der heutzutage viel schwammiger behandelt wird, als man das vielleicht früher gemacht hat.

Das ist richtig.

Der zeitliche ist für mich tatsächlich, der löst sich für mich halt auch auf.

Ich wollte es vom anderen Ende aufziehen gerade, weil ich jetzt ein paar Mal mit Leuten es davon hatte, dass eigentlich das, was bisher klassisch Projekte sind, inzwischen eigentlich Produkte sind.

Also ich habe ganz viele.

Ja, ich finde halt häufig schon wirklich Produkte in so einer Kombination tatsächlich auch, wir haben, also bei uns ist es so, wir haben ja gerne mal Kunden, die irgendwelche eher so Geschäftsansätze, Business-Ideen haben aus ihrem eigentlichen Geschäft raus.

Und die suchen sich irgendwen, der dieses eigentliche Produkt, also wenn da ein digitales Produkt raus entsteht, jemand anders, der es implementiert und irgendwer muss das Ding dann operativ irgendwie betreuen.

Und da kommt dann aber sofort so ein Perpetuum Mobile schon fast raus, wo man davor steht und sagt, okay, es ist halt kein Projekt, weil das ist halt zeitlich nicht begrenzt, sondern wir wollen das im Prinzip als wie eine Art Mini-Unternehmen nach vorne treiben.

Und es ist halt auch nur mäßig zielgerichtet im Sinne von, es gibt halt kein festes Ziel von, haben wir das erreicht oder nicht, sondern es gibt mehr ein, ja, wir haben hier irgendwie das Gefühl aus unserem Hauptbusiness raus, in dieser anderen Ecke, da verbirgt sich irgendwie ein neuer Markt.

Wir müssen mal gucken, was man da machen kann.

Lassen wir mal irgendwas dahin werfen, gucken, wie der Markt reagiert und dann rennen wir nachher, wenn wir rausfinden, dass es doof war, in genau wie entgegen die letzte Richtung.

Deswegen habe ich, deswegen bin ich so an diese Einmaligkeiten, an den Zielgerichtetheit und die zeitliche Abgrenzung, die löst sich da in der Folge so im Prinzip sozusagen automatisch auf.

Nur um das kurz einzuwerfen, da gibt es auch für diese Dinge, die du beschrieben hast, gibt es auch andere Worte noch in dieser, ich glaube, nicht in der DIN, aber in der Literatur, das heißen dann Programm oder Vorhaben oder solche Dinge.

Aber ich meine, ergibt sich das nicht quasi so relativ zwangsläufig aus.

Also wenn ich mir jetzt so vorstelle, also oder ich kenne das halt aus dieser ganzen Agile Welt halt sozusagen, es gibt so ein magisches Dreieck irgendwie an Ressourcen, die begrenzt sind und die man halt sozusagen nicht unabhängig voneinander irgendwie verändern kann.

Das ist halt Zeit, irgendwie Geld, das man dafür ausgibt und halt irgendwie, na, was war das dritte?

Qualität.

Ach ja, die wird immer so, die vergesse ich auch manchmal irgendwie.

Es gibt manchmal auch mal einen vierten davon.

Funktionsumfang.

Genau, genau.

Und das Problem ist jetzt sozusagen, dass zwei von den Dingern eigentlich nicht so richtig optional sind.

Also Qualität, wenn man eigentlich nicht offern oder die Features.

Und Geld, wenn man jetzt auch nicht auch nicht beliebig darum liegen, dann bleibt ja eigentlich nur die Zeit, die variabel sein kann.

Und die wird es dann halt auch irgendwie immer, sodass es halt irgendwie.

Ja, aber das ist doch die Aufgabe des Projektmanagers, dafür zu sorgen, dass es gestern fertig ist.

Ja, aber das ist halt noch völlig spannend.

Also es gibt ja verschiedene Perspektiven, die ihr jetzt genannt habt.

Es gibt halt die Perspektive von dem Kunden beispielsweise, der jetzt sein ganzes großes Projekt da hat und dann da Pivots machen möchte.

Und wenn er dafür Menschen beauftragt, die haben dann vielleicht ein kleines Projekt in diesem Projekt drin.

Das heißt, aus deren Perspektive ist das nur ihr eigenes abgeschlossenes Projekt, wenn dann ihre Aufgabe nach zwei Monaten erledigt ist oder so.

Obwohl das nur ein Baustein in einem großen Projekt des anderen war.

Und das ist halt wieder diese Verschachtelung vor den einzelnen Projektebenen.

Und die Frage ist, wie man das halt vernünftig hinbekommt, dass man das so organisiert, dass man einzelne, ich weiß nicht, Arbeitspakete hat.

Ich weiß nicht, ob ein Arbeitspaket ein geeignetes Maß ist, um ein Projekt zu managen.

Oder gibt es überhaupt Metriken?

Ist das wichtig, dass man irgendwas messen kann oder geht es um den Erfolg?

Also was ich spannend finde, was ich bei uns halt beobachte von der Granularität her, wir versuchen immer, und das geht ja auch um die Frage von, wie kann man solche Sachen verschriftlichen, welche Tools nimmt man dafür.

Wir schreiben gern ganz viele Sachen in Tickets rein.

Und uns ist es wichtig, dass wir ein System haben, wo alles, was irgendwie die Firma berührt, in Tickets landet, damit ich es halt auch ein bisschen kreuzreferenzieren kann, etc.

Und da ist tatsächlich für uns immer wieder dieses Thema, weil wir ja eher auch so ongoing als direkt projektorientiert sind.

Ich würde auch sagen, wir haben manchmal so Projekte, wo wir sagen, jetzt hat es hier irgendwie einen abgeschlossenen Fokus, wo wir mal für zwei, drei Monate versuchen, die sieben Sachen zusammenzubündeln und einmal durchzuprügeln, um sie dann auch immer wieder loszuwerden und sagen, jetzt brauche ich mich nicht mehr darum zu kümmern, jetzt denkt da keiner mehr drüber nach.

Jetzt haben wir gerade zum Beispiel das Netzwerk einmal bei uns saniert und dann war das halt mal für drei Monate was stärker im Fokus war und was eine ganze Reihe von zusammenhängenden Aufgaben hatte.

Und da finde ich zum Beispiel spannend.

Für mich gibt es so eine Balance und ich habe keine Ahnung, was eine gute Antwort ist, dass wir auf der einen Seite Unmengen Tickets generieren und für die Leute in so einem Team, in einer Firma hat das ganz unterschiedliches Gewicht, ob da jetzt zum Beispiel 5000 Tickets rumliegen, um die sich nie wieder an der kümmern wird.

Da denke ich mir so, das ist überhaupt kein Problem.

Die machen wir einfach alle zu, als ja, haben wir erfasst, steht da drinnen.

Wenn man mal irgendwann nochmal danach suchen möchte von, sagen wir, haben wir schon mal nachgedacht über XYZ, dann sieht man, ach guck mal, da gab es schon mal drei Sachen, warum war denn das?

Wieso?

Weshalb, warum?

Versus andere, die dann gegebenenfalls denken, jetzt kommt hier ein Ticket rein, fuck, das muss jetzt irgendwie abgearbeitet werden.

Ja, aufgeräumtes Backlog oder

das macht dann halt Stress und auch Backlog ist tatsächlich so, da neigen wir gerade eher dazu zu sagen, also alles, was nicht freiwillig sozusagen bei jemand innerhalb von zwei Wochen auf dem Tisch landet, kannst du halt im Prinzip auch gleich zumachen, weglegen, aber vernünftig ein bisschen mit Metadaten versehen.

So zu welchem Bereich gehörten das so grob, was hatten das noch für zwei, drei Tags oder so?

Und dann kann man, wenn man dann mal auf die Suche geht von so, okay, was haben wir denn im letzten Jahr für Notizen uns gemacht zum Thema XY, weil da wollen wir jetzt nochmal rangehen, dann kann man die dann wieder rausholen, aber du musst die nicht ständig pflegen und machen und tun und das hilft halt den Leuten auch, denn ihr sagt, ja komm, macht einfach Tickets immer her damit, immer her damit, immer her damit.

Dann hast du so ein bisschen organisationales Wissen halt auch an der Stelle, ja.

Wie macht ihr denn Tickets?

Wenn er gerade so bei Tickets sind mit Python oder

Macht ihr Tickets für wirklich alles?

Macht ihr Tickets auch für, keine Ahnung, Kaffeemaschine ist kaputt oder für, keine Ahnung, Kunde muss gefunden werden?

Ja, ja, genau.

Also das kommt immer drauf an, wer das halt macht.

Weißt du, also wenn die Kaffeemaschine, da muss ich gerade überlegen, es kann sein, dass meine Kollegin, die dafür zuständig wäre, sich da ein Ticket macht, um sich zu ändern, weil das halt auch in Summe den Alltags-Artsorganisationsflow abbildet.

Weil halt jeder, weil jedes Team halt so seine Flowboards auch hat mit was liegt denn hier irgendwie gerade im Team eigentlich so alles an und dann willst du halt auch sehen, ah, stimmt, die Kaffeemaschinen machen dies, das und jenes.

Und auf der anderen Seite habe ich aber halt auch häufiger mal Sachen, weil auch ein Ticketsystem relativ schwergewichtig ist, habe ich so meine eigenen kleinen To-Do-Listen noch, wo ich dann irgendwann sage, jetzt schreibe ich das ja ewig rum, jetzt ist es mal wieder zu viel geworden, jetzt mache ich da irgendwie Tickets draus, damit ich es wieder auch anderen Leuten im Team geben kann.

Okay.

Es ist spannend, dass ihr alles über Tickets macht.

Ja, aber ich kann das total verstehen, dass das für unterschiedliche Leute eine total unterschiedliche Bedeutung hat.

Ich kann aber auch verstehen, dass es Leute gibt oder dass es vielleicht Positionen gibt, die damit überhaupt nicht klarkommen, weil die eben nicht so einzelne Arbeitspakete haben, sondern weil die vielleicht eher event gesteuert sind oder weil die eher dauerhafte Aufgaben haben.

Also das klassische Beispiel ist halt ein Callcenter-Mitarbeiter, der wartet halt auf einen Anruf, der kann keine Tickets bearbeiten, um es mal sozusagen, bis ihn jemand anruft.

Und da hilft auch nichts, wenn er zehn Tickets auf seinem Tisch hat, weil er halt auf dieses Event warten muss.

Umgekehrt gibt es natürlich so Sachen, die ongoing sind, ja, dass du halt, du musst halt jeden Tag, keine Ahnung, die Post abholen und du musst jeden Tag die Rechnungen verschicken und du musst jeden Tag die Eingänge prüfen, was weiß ich.

Und dafür Tickets zu haben.

Stelle ich mir auch schwierig vor.

Also diese Ticket-Sachen passen schon eher zu dem, was man so als Softwareentwickler halt macht, dass man was.

Na, das kommt total darauf an, weil wir haben im letzten Jahr eine ISO 727.000 gemacht und da musst du relativ viele Prozesse auch zumindest so formalisieren, dass du halt nachweisen kannst, dass Sachen, die passieren sollen, auch passiert sind.

Wenn du dann eh schon ein Ticketsystem hast, wir haben jetzt bei uns so eine Kombi, da kann man in dem, wir haben so ein MediaWiki für die Dokumentation, für die Prozessdokumentation, und dann kannst du in einer Wiki-Seite so ein kleines Template anlegen, das komische MediaWiki generiert dir da auch gleich so richtig Formulare für.

Und jetzt kann man bei uns auf einer Wiki-Seite sagen, zu diesem Prozess gehört es, dass einmal im Quartal jemand irgendwie nachguckt, ob im OnePassword irgendwie die richtigen Leute drin sind oder noch Leichen rumfliegen oder irgendwie sowas.

Und dann gibt es tatsächlich einen Conjob, der aus diesen Daten dann die Tickets generiert zum richtigen Zeitpunkt und du kannst sozusagen so Wiedervorlage-Tickets in der Prozessdefinition hinterlegen.

Und das ist dann auch so ein Mittelweg zwischen, ja, also alles, was man täglich machen muss, das brauchst du, glaube ich, nicht in Tickets nachweisen.

Aber wenn es dann plötzlich auf alle zwei Wochen, vier Wochen, acht Wochen geht, dann willst du dir vielleicht schon eher Erinnerungen machen können.

Ja, aber dann ist es ja wirklich eher erstmal so ein To-Do-Item, also sowas ganz Leichtgewichtiges.

Genau.

Es gibt ja auch Tickets, wo du acht Wochen brauchst und ein Team von zehn Leuten zu bearbeiten.

Da diese Spanne, finde ich auch was ganz Spannendes, ganz, ganz, ganz Spannendes.

Das ist auch das, was der Dominik eben angesprochen hat.

Und das ist so im Wesentlichen die Kernfrage von Projektmanagement.

Wie groß sind die Projekte, die man macht?

Sind die ganz klein?

Sind die eine Woche lang eine Person?

Oder sind die ganz groß?

Vier Jahre und ein Team von 150 Leuten.

Und wie dröseln wir das dann auf, wer was an welcher Stelle in welchem Projekt macht?

Da würde ich sagen, erfahrungsgemäß sind die eher groß.

Also die Sachen.

Klassischerweise ja.

Ja, die irgendwie dann ein einzelner Entwickler macht oder so, die sind ja dann meistens, aber die nennt man dann ja nicht Projekt, sondern das ist dann halt irgendwie ein Task oder eine User-Story.

Definitionsgemäß sind es natürlich schon auch Projekte.

Ja, gut, okay.

Aber die gehören immer zu irgendeinem, also es gibt immer meistens eine Projektnummer, auf die das dann irgendwie gebucht wird oder so.

Und diese Projektnummern sind sozusagen, ich weiß nicht, die werden irgendwie mal beim Urknall erzeugt worden sein und die sind halt ewig.

Die verändern sich auch nicht.

Ein Projekt ist einfach nur eine Kopf.

Ja, krass.

Die Herren S A und P irgendwann mal erzeugt.

Nee, da geht es ja dann wieder tatsächlich noch in den anderen Bereich rein, dass Projekte auch ein Kommunikationsmittel sind und auch eine gewisse vertragliche Vereinbarung enthalten können, weil Projekte eben ein Mittel sind, wie man mit einem Kunden kommunizieren kann.

Wenn du sagst, okay, wir machen jetzt erstmal ein Projekt.

Und dann hat das hat eine gewisse Schwere.

Das ist nicht was, was du einfach so machst, sondern wir machen mal ein Projekt und das hat gewisse Komponenten, die da sein müssen.

Weil du den zeitlichen Rahmen festlegen musst, weil du die Ressourcen festlegen musst, weil du das Ziel festlegen musst.

Ja, aber dafür braucht man ja schon die ganze Information, die man vielleicht ja noch gar nicht hat.

Das heißt, was man da irgendwie machen muss, ist irgendwie so eine Pi mal-Daum-Schätzung oder die mehr oder weniger valide Schätzung abzugeben.

Ja, klar.

Aber das ist ja nicht möglich bei unbekannten Dingen.

Also das geht ja nur dann, wenn man sowas schon mal kennt.

Ja gut,

du hast halt ein Projekt, was eventuell sein Ziel nicht erreicht oder was verlängert werden muss oder was über Budget geht, aber das haben wir ja, glaube ich, alle schon mal erlebt.

Pass man die Sachen mal an.

Also immer.

Aber es ist eigentlich ein gutes Projektmanagement.

Ja, also da merke ich auch, da versuche ich eher anders an die Sachen ranzugehen.

Wir haben so ein bisschen den Vorteil, dass wir typischerweise eben aus dieser operativen Sicht kommen, wo eh alles ein Ongoing-Consign ist im Prinzip.

Und wo man dann halt auch mal sagen kann, so ja, okay, jetzt machen wir hier mal irgendwie eine.

Wir machen praktisch keine Projektarbeit, aber natürlich haben wir das Thema, dass halt bestimmte Innovationen oder bestimmte Änderungen oder bestimmte Weiterentwicklungen halt irgendwie aufgefangen mit begleitet werden müssen, umgesetzt werden müssen, etc.

Und ich habe aber halt, aus dieser Beschäftigung mit den Komplexitätstechniken, so rund um Kinevin, etc., komme ich dann halt eher da rein zu sagen, naja, entweder ist das etwas, was wir kennen, dann sehe ich zu, dass das so gut wie möglich automatisiert und operationalisiert wird.

Dann brauche ich, dann habe ich aber einen Ongoing Concern daraus gemacht.

Oder es ist was total Unbekanntes.

Und in einer komplexen Welt will ich bei was Unbekanntem mir nicht schon ein Ziel setzen, weil ich damit halt psychologisch das Problem aufmache, dass ich halt unterschätze, wie viel Erkenntnisgewinn ich auf der Reise eigentlich einsammle, um dann zu dem eigentlichen Ziel zu kommen.

Und deswegen ist es,

glaube ich, das, was der Dominik sagen wollte, oder?

Ja, also ihr müsst vielleicht erstmal nochmal die ganzen kleinen Sachen definieren, die unsere Hörer vielleicht gar nicht kennen, zum Beispiel was denn Knevin?

Knevin ist ein Ansatz von einem walisischen Professor namens Dave Snowden, nicht verwandt mit Edward Snowden, und der beschäftigt sich so seit den 80ern mit Knowledge Management, war lange bei der IBM und hat beschäftigt sich mit komplexen Systemen, auch komplex adaptiven Systemen genannt.

Und schreiben, geschrieben wird Knewin mit C, Y, N, E, F, I, N.

Die Baliser haben sehr lustige Ausspracheregeln, deswegen kommt da dann am Ende Knevin raus.

Und da geht es zum Beispiel darum, dass man halt multimodale Entscheidungssysteme braucht, dass du halt in der Lage sein musst zu sagen, ja, für bestimmte Arten von Problemen muss ich halt unterschiedliche Lösungsstrategien angehen können.

Und gleichzeitig ist es auch nicht so, dass ein bestimmtes Problem absolut betrachtet, einer bestimmten Komplexitätsklasse zuzuordnen ist, sondern die Frage ist mehr, kann ich mir unterschiedliche Perspektiven ranziehen?

Also er hat solche Sachen wie ungeordnete und geordnete Systeme, komplexe Systeme, wo ich retrospektiv erklären kann, wie die Zusammenhänge hier eigentlich sind, oder chaotische Systeme, wo ich auch retrospektiv nicht mehr sagen kann, wie es eigentlich dazu gekommen ist.

Oder geordneten Systemen, wo ich halt einen Experten, einen Ingenieur dran setzen kann, dem das Problem schüler, der dekliniert das durch und sagt mir, die Antwort ist X.

Oder halt eher bürokratische, einfache geordnete Systeme, wo ich halt sei es, okay, wenn der Herr einen Ausweis will, dann müssen wir hier halt das Verfahren X abarbeiten und dann kommt da hinten ein Ausweis raus.

Und was da spannend dran ist, ist halt, das nicht ontologisch zu betrachten von, ja, ist ein Problem jetzt einer dieser Domänen zuzuordnen, sondern die Frage ist, was lerne ich über ein Problem, wenn ich es aus einer dieser Brillen halt betrachte?

Um es dann gegebenenfalls zu zerteilen und zu fragen, was in diesem Problem wäre denn etwas, was man mit Expertenwissen erschlagen kann, wo sich jetzt einer mal mit einer Timebox eine Woche Zeit nimmt und sagt, so, dekliniere das mal durch, habe ich danach eine Lösung?

Sehr gut.

Oder ist die Frage, ist es komplex, müssen wir im Prinzip erst anfangen, mit dem Ding ein bisschen zu spielen, um was drüber zu lernen, um dann zu gucken, ob wir es weiter zergliedern können, um zu wissen, aha, hier geht es in die richtige Richtung, geht es in die falsche Richtung, oder brennt mir hier gerade irgendwie alles ab und ich muss erst mal draufhauen und danach fragen?

Und das sind Ansätze, wo ich merke, die gehen so weit weg von einem im klassischen Projektmanagement stark bürokratieorientierten Ansatz.

Also ich bin ja, ich bin zur Uni gegangen, das war 2001 bis 2003, da sind wir ja noch mit diesen klassischen Wasserfallmodellen konfrontiert worden, während wir gleichzeitig, gleichzeitig kam 2001 das Agile Manifesto raus.

Und als Studenten hatten wir halt dieses Agile Manifesto vor uns.

Wir hatten unsere Profs und irgendwie Function Point-Schätzungen gab von, du musst ein Projekt halt in alle möglichen definierbaren Teile zergliedern, die dann entsprechend schätzen und bepreisen.

Ja, dann addierst du dir halt auf und dann bist du halt fertig.

Und diese Ansätze berücksichtigen ja keinerlei Interaktionen und Erkenntnisgewinne auf der Reise oder wie Dinge halt komisch sich verzweigen.

Und heute sind wir dummerweise wieder an einem Punkt, ich nenne das dann immer Weaponized Agile, dass man halt eben sagt, agil ist jetzt, wenn eine große Firma sich Scrum einkauft, jedes Team genau den gleichen Arbeitsmodus hat und alle zwei Wochen seine Tickets abliefert und ich gucke auf das Agile-Manifesto und denke mir so, ja Moment, nee, da stand erstmal drauf, dass es um funktionelle Software und ordentliche Zusammenarbeit und dass das Team im Prinzip sich überlegen muss, was denn in diesem Projekt jetzt ger

ade der richtige Arbeitsmodus ist.

Und allein schon eben dieses Thema, du sagst es ja auch, das ist jetzt mal ein Task oder ein Ticket, da brauchst du zehn Leute für acht Wochen, da platzt ja jeder Scrum Master.

Haben wir aber alle schon mal gehabt, solche.

Ja, das

ist halt so, wo ist denn das Problem?

Ja, gut, ich würde jetzt sagen, so aus Agile-Perspektive ist es halt so, sowas sollte man sich nicht vornehmen, weil einfach das Risiko, dass das schief geht, ist halt zu hoch.

Kann man das nicht vielleicht irgendwie ein bisschen in Teile aufteilen, aber und das geht ja dann meistens auch irgendwie.

Ja, aber ich finde das sehr interessant.

Und ich finde, also möglicherweise, ja, eben, was man für Probleme hat, hängt halt unter Umständen auch damit zusammen, eben, ob man jetzt eher Projektgeschäft macht oder eher irgendwie operative Geschichten, so Produktionen.

Ich glaube auch, dass da ein großer, dass da noch ein wichtiger Unterschied ist, den man vielleicht nicht so, ja, ansonsten, wenn man das sich jetzt schon auf irgendeine Methodologie einschießt, vielleicht nicht so wahrnimmt, aber der ist, der ist, glaube ich, tatsächlich sehr relevant und es geht üblicherweise in eine bestimmte Richtung immer sehr schief.

Nämlich, man hat halt einen Unterschied, wenn ich jetzt zum Beispiel bei Softwareentwicklungen, wenn ich darüber nachdenke, wie funktioniert das?

Was macht man da eigentlich im Gegensatz zu, weiß ich jetzt nicht, zum Beispiel irgendwas, man hat ein Fast Food-Franchise Restaurant, irgendwie sowas.

Hast du Hunger?

Ein bisschen.

Okay.

Mal gucken.

Ja, Softwareentwicklung hat halt immer auch so was Exploratives dabei, oder?

Man weiß am Anfang noch nicht, wie die Lösung ausmacht.

Ja, naja, sag mal so, die Prinzipien, also wie man das managt, ist halt sozusagen fast umgekehrt.

Also bei einem bei so einem Fast Food-Franchise würde ich sagen, also man muss Sachen standardisieren.

Man muss halt zusehen, dass irgendwie keine Fehler passieren.

Kinuierlich senkt, dass keine Überraschungen passieren, dass alles irgendwie so wie es im Buch steht, halt gemacht wird.

Man muss halt irgendwie dafür sorgen, dass die Leute irgendwie pünktlich zur Arbeit kommen und dass halt irgendwie die ganzen formalen Geschichten eingehalten werden.

Das ist alles total wichtig.

Und keine Experimente.

Es gibt irgendwo eine Zentrale, da überlegen Sie sich vielleicht neue Rezepte oder so, aber irgendwie die Leute im Restaurant sollen halt austauschbar sein und die sollen halt irgendwie funktionieren.

Und das Ganze ist quasi so eine Maschine und die soll halt laufen, damit da irgendwie Cheeseburger rausfallen und die Leute glücklich sind oder dick oder was auch.

Ja, aber das löst doch auch nur so ein gewisses Problem, oder?

Genau, das löst halt dieses.

Ja, also aber das Ergebnis davon ist halt ein Fastfood-Hamburger.

Und wenn du einen guten Hamburger essen willst, gehst du nicht zu einem Fastfood-Laden, weil da kriegst du zwar immer den gleichen und auch auf der ganzen Welt überall immer den gleichen.

Aber du kriegst halt auch immer nur den Fast Food-Burger.

Ich glaube auch, also genau.

Ja, also was du ja beschreibst gerade, ist eben, das ist die Optimierung auf Effizienz, ja.

Das ist, du willst möglichst viel Output mit möglichst wenig Input haben.

Das ist Effizienz.

Und bei

Standardisierung, du willst immer den gleichen Output haben.

Je gleicher

der ist, umso besser.

Genau, du willst, du willst halt, du willst auch wenig Variation da drin haben.

Ja, ja, genau.

Die Seite bei der Softwareentwicklung und Explorativen ist halt, solange du gar nicht weißt, was du tust, musst du ja erstmal an der Wirksamkeit der Lösung arbeiten.

Du musst erstmal die Effektivität herstellen.

Du musst erstmal fragen, tue ich hier eigentlich das Richtige?

Und ich meine, das willst du halt auch nicht.

Also es ist jetzt philosophisch abstrus.

Ich müsste sehr an die Simpsons denken.

Irgendwie da den einen Jugendlichen, der immer beim Hamburger Journal, du willst nicht, dass der sich die Frage stellt, ob er hier gerade das Richtige tut.

Das willst du halt nicht.

Der kommt nachher auf die Idee, seinen Lebenssinn irgendwie in Frage zu stellen.

Das wäre für den Output der Burger jetzt eher schwierig.

Nachher sagt er, ich will gar nicht arbeiten.

Ich würde sogar fast noch einen Schritt weiter gehen und sagen, bei Software weiß der am Anfang oft gar nicht, was das Ergebnis sein soll.

Genau.

Solange du nicht weißt, was du für einen Burger haben willst, kannst du auch keinen Prozess machen, diesen Burger-Hashtag.

Und Achtung, natürlich gibt es da einen Zwischenton im Sinne von, wenn du mit deinem Handwerkszeug effizient umgehen kannst, im Kleinen, im Sinne von, wie schreibe ich Code und wie strukturieren wir eine Softwarebasis, etc., dann kannst du natürlich kostengünstiger mehr explorativ machen, als wenn du die ganze Zeit nur dabei bist, irgendwie dagegen zu...

Also wer nicht zehn Finger schreiben kann, nicht jeder muss zehn Finger schreiben können, aber wer halt, wer Schwierigkeiten hat, eine gewisse Menge Code effektiv und effizient ins System reinzukriegen, der kann halt nur schwierig experimentieren, weil es halt sehr teuer ist, halt mal vorwärts, rückwärts, links, rechts.

Und da ist aber auch tatsächlich diese klassische Projektmethodologie drin, du willst die Fehler während des Prozesses minimieren, weil die nach hinten heraus halt explodieren, während wenn du sagst, naja, es ist für mich leicht, schnell viel Code zu produzieren, zu testen, anzugucken und drüber nachzudenken und dann die nächste Iteration reinzugehen, dann brauche ich nicht von vorne nach hinten alles ausdefiniert haben, sondern kann es mir leisten zu sagen, Code ist auf eine gewisse Art ein lebendes Gespräch mit einem komplexen System, um zu sagen, so,

was passiert denn hier, wenn ich jetzt diese Menge von Code reinstreue?

Daraus entstehen neue Ideen und dann kommst du dahin zu sagen, und das ist das, wo wir nämlich, wo ich dann wieder andocke mit, das ist dieses Ongoing, äh Software-Entwicklung als Ongoing-Concern eines Produktmanagements.

Dann willst du aus so einer Kombination aus, da gibt es Leute, die haben halt ein Business-Anliegen, da gibt es Leute, die können Software entwickeln, dann gibt es Leute, die betreuen sowas operativ und aus denen willst du einen andauernd laufenden Co-Creation-Prozess bauen, wo jeder im Prozess die Möglichkeit hat, Erkenntnisse einzufüttern, um dieses, was tun wir eigentlich weiterzuentwickeln und anzufüttern und nicht nur dieses, ja, haben jetzt alle ihre Aufgaben gemacht, dann ist jetzt das Projekt vorbei, dann brauchen wir es jetzt für fünf Jahre nicht anfassen und das läuft jetzt hier vor sich hin.

Ein Co-Creating.

Das ist schön.

Naja, das ist halt, wenn man mal versucht, irgendwie dieses blöde Thema Digitalisierung mit irgendwas sinnvoll zu unterfüttern, then finde ich sind halt, ist gerade so ein Begriff wie Co-Creation das, wo man tatsächlich Wert schöpfen kann, wo du wirklich sagen kannst, was ist jetzt an Softwareentwicklung, außer von, ja, wir haben es jetzt perfektioniert, möglichst schnell Fachanwendungen mit immer den gleich aussehenden Formulareingabefenstern auszukotzen.

Was kann man da eigentlich besser machen?

Und besser machen ist eben tatsächlich die Sage, naja, du willst in den Alltag rein bis zum Nutzer diese Konversation mit dem komplexen System von was tun wir hier eigentlich und was geht eigentlich unterfüttern.

Nevin in diese komplexen heißt das unarticulated needs, weil du halt das Problem hast, dass die Leute, die das Zeug einsetzen, die ihr vorher, die verstehen heutzutage nicht, was kannst du eigentlich alles bauen.

Und du kannst nicht kommunizieren, was in ihrer Domäne jetzt vielleicht sinnvoll wäre zu bauen.

Das heißt, du musst auf eine gemeinsame Reise gehen, um eine Sprache zu entwickeln, um tatsächlich im täglichen Dienstag früh um sieben, mein Patient ist komisch ausgerutscht, weil das Programm mir gestern vergessen hat, auf eine sinnvolle Art zu sagen, dass da bitte eine Mathe hinzulegen ist.

Diese Schleifen brauchst du halt nicht am grünen Tisch irgendwie von irgendeinem Produktmanager.

Du brauchst diese Schleife tatsächlich zwischen bis zu, da ist der Patient hingefallen, weil XYZ.

Und diese Informationen ordentlich durch die Gegend zu leiten, ist tatsächlich immer auf einer ganz anderen Ebene, als was man klassischerweise unter Projektmanagement verstehen würde, ja.

Das ist jetzt aber schon ein sehr agiler Ansatz, dass du den Kunden direkt in das Projekt einbettest und dass du erstmal den Kunden beobachtest und dass du das

kleinen modern machen, oder?

Aber nochmal ganz kurz, um das mit den Produktions.

Also ich meine, genau, da finde ich alles richtig.

Ich würde jetzt nur sagen, was ich oft sehe, was Leute tatsächlich, oder wo ich auch denke, dass es läuft einfach immer oder oft schief, ist halt, dass wenn ich jetzt so ein Projekt habe, wo eigentlich all diese schönen Sachen gemacht werden sollten, wie wird das in der, äh, wird das oft in Firmen gemanagt, dann wird es so gemanagt, als wäre das ein Burger-Franchise.

Und das ist eigentlich fast genau falsch rum.

Weil eigentlich müsstest du ja sozusagen, wenn du nicht weißt, wo es, also wenn du all diese komplexen Probleme hast, musst du eigentlich zum Beispiel eben experimentieren eigentlich sozusagen mehr vorantreiben als verhindern.

Du musst halt irgendwie sagen, okay, naja, Fehler können halt passieren.

Es kann sein, dass man mal eine Zeit lang in eine falsche Richtung läuft.

Da muss man sich halt umdrehen und in andere Richtungen laufen.

Was man aber tatsächlich oft sieht, ist halt sehr defensives Management an der Stelle.

Zum Beispiel, also ein, also alle sagen immer, dass Fehler gut sind und dass es kein Problem ist und dass man da draus lernen kann und anders gar nicht lernen kann und so, das also Lippenbekenntnisse hört man oft.

Aber was man auch in den meisten Organisationen, also ganz oft, was ich da höre, ist immer sowas wie, ja, wenn man zum Beispiel jetzt sieht in einem Projekt irgendwie, das ist so ein bisschen in eine Sackgasse gelaufen, dann sieht man das so, als zum Beispiel jemand, der so extern dazukommt, und denkt sich so, hm, also da geht es irgendwie nicht weiter.

Und dann spricht man das an und dann oft erst so informell und dann kriegt man halt zurück, ja, ja, das wissen wir ja alles, aber das geht jetzt halt nicht anders.

Und das läuft schon so lange.

Und das machen wir das lieber schrittweise, machen wir lieber Tickets und so.

Und man denkt so, ja, aber wo soll das hinführen?

Das geht nirgendwo hin, das ist ein Dead Ender.

Ja, da ist schon freigegeben.

Du hast schon die Freigabe, dann musst du es

auch machen.

Ja, aber genau, und dann kann man.

Das ist halt dann aber nicht mehr, wenn das nicht geht, dann, und das ist ganz ungefähr, oder wenn Leute sagen, wenn man dann sagt, okay, probieren wir das einmal, nee, das ist politisch nicht durchsetzbar, dann weiß man, okay, hier sind Fehler nicht so richtig erwünscht, weil jetzt, da haben alle schon gelernt, wenn man jetzt sagt, okay, das war ein Fehler, wir machen es jetzt anders, dann ist das politisch keine gute Idee, weil Fehler wohl offenbar doch keine so gute Idee sind.

Und wenn man jetzt Leute, also man könnte zum Beispiel Leute fragen, irgendwie, ja, was war denn eigentlich die letzte fiese Architekturfehlentscheidung, die so passiert ist und wenn Leute sagen, es nie passiert, oder Projekt, das eine Sackgasse ist, wo man mal, wenn Leute sagen, sowas passiert nicht, nie, dann ist das zu wenig, weil das ist nicht optimal.

Also optimal wäre durchaus, ab und zu sich zu urnen und irgendwie mal in eine Sackgasse zu laufen und dann halt wieder umzudrehen.

Also ja, das ist halt

das kommt vielleicht auch alles so ein bisschen aus dieser Welt, die der Tony vorhin schon angesprochen hat, dass ganz viel nach Waterfall gemanagt wird.

Und das geht halt nicht.

Es ist in den Köpfen irgendwie drin, ja.

Ein agiler Wasserfall.

Übrigens, dieses Waterfall-Modell, das ist definiert worden von Royce Winston.

Ist schon ganz lange her.

Ich würde euch die Jahreszahl sagen, aber ich finde sie gerade nicht.

Und war eigentlich als Negativbeispiel gedacht.

Es war eigentlich gedacht als Beispiel von so geht Software Management nicht, so kann man Projekte nicht managen.

Nur leider hat niemand.

Dann machen wir das jetzt so.

Es hat niemand über die erste Seite hinausgelesen und nur dieses erste Diagramm ist das, was man da immer sieht.

Das kennt.

Auch in diesem ersten Paper steht schon drin, als eine von den Sachen Involve the Customer.

Also sprich mit den Leuten, die das dann benutzen sollen und benutzen müssen, weil nur die wissen, was da an Anforderungen tatsächlich drin ist.

Nur die wissen, was die tatsächlich brauchen.

Das erste wäre mal, einen Kunden zu finden.

Einige Leute fragen dann irgendwelche Leute, wo die denken, das sind ihre Kunden, sind es aber gar nicht und die erzählen dann irgendwelchen Unsinn.

Ja gut, aber da kannst du mit Projektmanagement nichts dagegen tun, dass der Fehler ein anderer auf einer anderen Ebene hast.

Ja, wobei das Problem ist, das zu merken, kann schwierig sein.

Also ich habe, ich würde gerne ein paar Stellen dort andocken und aber da gibt es eine Anekdote, wo wir auch genau dieses Thema hatten, so um 2002, 2003 rum, Agile und Kunden mit einbeziehen und Customer on-Site, ja, den Kunden mit ins Team holen, haben wir dann gemacht.

Was macht der Kunde?

Hat uns jemanden geschickt und der war dann auch später immer wieder im Projekt.

Und da haben wir irgendwann, das hat lange gedauert, bis wir es gemerkt haben, weil auch wir die Erfahrung an der Stelle noch nicht hatten.

Der hat halt irgendeinen billigen Mitarbeiter geschickt, also irgendeinen Praktikanten, weil der FDL wollte, der war halt entbehrlich, der durfte aber nichts entscheiden.

Das heißt, der hat sich auch bloß immer umgedreht und hat mit zu Hause telefoniert, wollte aber natürlich auch ein bisschen eingebunden sein.

Und ich habe irgendwann tatsächlich realisiert, der hat uns immer so ein paar SQL-Claries geschickt für Sachen, wo er gerne noch Auswertungen für hätte.

Und das lief immer nicht sauber.

Da hat immer irgendwas in der Syntax gehackelt, etc.

etc.

etc.

Und irgendwann kam er an und sagte, so die Endung vom letzten Mal habe ich der rote markiert.

Und dann ist der Groschen gefallen, der hat die nie ausgeführt.

Der hat nur bei sich am Rechner gesessen and in seinem Word SQL Queries runtergeschrieben, die er mir dann geschickt hat.

Nur damit ich dann feststelle, yeah, this geht er forne and as er then meinte rot markiert, hat er tatsächlich dann halt angefangen, das Word-Change-Tracking zu nutzen um mir, also im Prinzip war ich Du warst quasi der Compiler.

Ich war sein Word-E-Mail-basierter Postgres-Interpreter, der dann immer zurück mit den Fehlermeldungen von der Postgres-Chell kam.

Das war halt so eine völlig, also bis man das auch merkt, dass dieses Customer Onset da völlig daneben gelaufen ist, hat gedauert.

Ich würde sagen,

man darf auch auf die Kunden nicht zu viel hören.

Das ist auch so ein Problem, was man heutzutage manchmal hat, weil die Kunden oder die Benutzer oft ganz verrückte Vorstellungen haben.

Wie du genau verständlich, die Kunden wissen nicht, was man bauen kann.

Und das heißt, entweder sagen sie, ja, es wäre schon gut, wenn man hier Text eingeben könnte und du denkst, ja, das konnte man 1970 schon.

Andererseits kommen sie dann und sagen, ja, aber der muss doch erkennen, dass da eine, welche Person da auf dem Bild ist und denkst dir, ja gut, Google kann das, aber wir können das halt nicht.

Welcher ist denn der Mensch, der das so entscheidet?

Ist das der UX-Mensch, der das kann?

Diese Sprache sprechen mit, wer der Kunde ist und was der eigentlich

produziert hat.

Es muss auf jeden Fall so eine Rolle geben, der diese Sprachen spricht und das ist ein Zeichen von erfolgreichem Projektmanagement und erfolgreicher Softwareentwicklung, dass es so eine nicht eine übergeordnete, sondern so eine vermittelnde Rolle gibt, der sowohl mit der Softwareentwicklungsseite sprechen kann, als auch mit der Kundenseite.

Also idealerweise bräuchte man in jedem Projekt einen, der zum Kunden gehört, aber in seiner Freizeit Open Source Software entwickelt.

Weil diese Brücke schlagen kann.

Nur so jemanden gibt es halt oft nicht.

Und dann denkt sich das jemand aus und wenn das jemand ist, der zu wenig Empathie hat, dann denkt er sich halt aus, dass die Leute es nicht wissen müssen, was sie müssen müssen.

Und dann kriegst du so Projekte, die irgendwo hinlaufen, die irgendwas herstellen, was dann keiner haben möchte.

Und tatsächlich, also diese Art von Übersetzung ist, ich würde nochmal andocken wollen, weil mir fällt tatsächlich auf, das habe ich gar nicht gedacht in der Vorbereitung, dass mir jetzt die ganzen komplexitätsbasierten Ansätze da alle reinlaufen.

Ja, ja.

Es ist halt dummerweise auch ein Steckenpferd und es dockt mental halt überall an.

Das eine ist das Thema Fehlerkultur, da bin ich dort auch nochmal auf den Trichter gekommen.

Es wird dort auch bezeichnet, dass wenn du in einer komplexen Welt bist, wo du halt die Interaktion nicht vorhersehen kannst, musst du parallele Experimente machen.

Das Spannende ist tatsächlich zeitlich parallel.

Ist das so AB-Testing oder was kann man das so

kurz sagen?

Ja, noch nicht mal.

Du willst ja nicht nur zwei machen, sondern du willst im Prinzip, was du machen möchtest, ist, du willst, es geht ein bisschen in die Richtung AB-Testing, aber schon vorgeschaltet, im Prinzip schon währenddem du entwickelst, zu gucken, in welche Richtung entwickelt sich was.

Und du willst dir sozusagen für ein gestelltes Problem, wo du die Lösung eben nicht a priori bestimmen kannst, sondern eben Softwareentwicklung erst entwickeln musst, willst du dir mehrere Theorien ausdenken, die tatsächlich auch so geartet sind, dass du, du brauchst immer mindestens drei, lieber fünf bis sieben, wo du weißt, A, es gibt eine gewisse Menge Widerspruch zwischen den unterschiedlichen Ansätzen.

Dass also, wenn du anfängst, sie zu implementieren, nicht alle tatsächlich valid sein können.

Dann hättest du nämlich nichts gelernt.

Und du willst auch machen, dass du bestimmte Ansätze nochmal um die Ecke denkst.

Da ist es immer hilfreich, wenn man im Team nochmal irgendwie naive Leute hat, also Leute, die noch nicht so lange dabei sind oder die Quereinsteiger sind und so.

Und da kommt dann nämlich dieses Thema, diese Experimente, die dann halt auch schon zum Beispiel in einem agilen Projekt, der schon mal nach zwei Wochen ausgerollt werden können.

Keine Ahnung.

Wir bauen jetzt hier eine, ich übertreibe in Richtung Einfachheit, wir bauen eine Zinsberechnungsfunktion und wir implementieren jetzt aber drei verschiedene Varianten, weil wir noch nicht wissen, welche davon jetzt die richtige ist.

Und tatsächlich kannst du sagen, da machst du zum Beispiel A, B, C-Testing.

Und das Wichtige ist, die müssen halt fehlerresistent sein, in dem Sinne von, dass du halt vorher dich fragst, was mache ich denn, wenn ein Fehler auftritt?

Dann kannst du dir solche Strategien zurechtlegen wie, naja, wir machen jetzt ein Monitoring, wenn eine von den Komponenten, eine von den Implementationen erhöhte Fehlerraten hat, dann nehmen wir die halt raus und lassen halt nur noch die anderen antworten und gucken dann, was irgendwie los ist.

Oder was machen wir, wenn eine von denen irgendwie total die volle, tolle Performance hat und macht, dass sie super skaliert?

Ja, okay, dann komm mit mir uns halt zeitiger auf die.

Und das Interessante zum Thema Fehler ist halt, auf der einen Seite, du musst es so designen, dass irgendwas davon tatsächlich Fehler wirft.

Sonst hast du nämlich deinen Optionsraum nicht ausreichend ausgesucht, wenn du nicht bis ans Ende and über Limit gegangen bist.

And that finde ich is halt zum Thema Fehlerkultur extrem wichtig.

Ein Fehler ist an der Stelle nicht etwas, was hoppla passiert is, sondern du designs das von vornherein, dass da ein Fehler passieren muss, weil sonst hast du nichts gelernt.

And that is name then, when you say Lippenbekenntness, a massive denkfahrer, not an jail passiert, that's that feeler of it, sort of nein, nein, nein, nein.

We set us here in and we designen this, where we won't we wish not what the answer is.

And one of the four things will chief gehen.

We won't have welche, but iron was chief gear.

And we bereiten uns darauf vor what we can when this chief gear.

And that was for me a massive Erkenntnis zum Thema, yeah, this halbherzige Fehlerkultur ist kaputt, weil man denkt, Fehler sind immer noch etwas, was man im Idealfall vermeiden kann.

Und das muss hingehen zu Fehler sind etwas, was ich provoziere, weil ich erst dann den Optionsraum so weit ausgeschöpft habe, dass ich echte Innovation treiben kann, dass ich eine echte Erkenntnis hatte.

Ich muss vielleicht nochmal kurz dazu gehen, wie provoziert man denn so einen Fehler und worum geht es dabei?

Ja, indem du Theorien aufstellst, die sich widersprechen.

Du sagst halt, du hast eine bestimmte Aufgabe und du weißt noch nicht, was die möglichen Ergebnisse sind.

Beispiel.

Bild, bildlich gesprochen.

Du bist irgendwo mitten in der Wüste und deine Aufgabe ist rauszufinden, in welche Richtung geht es jetzt hier eigentlich ordentlich voran.

Ja, wo müssen wir hin?

Zum Wasser.

Zum Wasser oder zum Meer oder was auch immer.

Dann schickst du also vier Leute oder du versuchst rauszukriegen, wie weit geht es denn hier eigentlich.

Und dann schickst du halt vier Leute in vier Himmelsrichtungen und jetzt kannst du entweder sagen, naja, ich lasse die alle jeweils einen Kilometer laufen und dann zurückkommen, dann können sie dir sagen, ja, hier geht es jeweils in ein Kilometer Richtung.

Schön.

Jetzt hast du aber noch nicht gelernt, wo hier Ende ist.

Das heißt, du musst im Prinzip an der Stelle eher sagen, naja, du machst vier Experimente und jedes davon läuft so weit, bis es irgendwie mindestens irgendwo anstößt.

Und anstoßen kann halt, wenn du Pech hast, heißen, da fällt jemand eine Klippe runter.

Das wäre ein Fehler.

Er verdurstet eine Wüstenland.

Er verdurstet halt irgendwo eine Wüste.

Ja, ja, ja, das ist vielleicht sogar, das wäre schon ein Beispiel an der Stelle.

Und du weißt vielleicht, ja, irgendwo ist eine Oase, aber halt eben nicht überall.

Dann machst du halt Theorien und sagst, naja, die höchste Wahrscheinlichkeit ist, dass in einer von den vier Richtungen irgendwo eine Oase ist, aber es kann nicht überall eine sein.

Und damit müssen sich die, die sich auf diese Expedition begeben, darauf vorbereiten, dass sie derjenige sind, der keine Oase findet.

Was mache ich denn dann?

Ja, idealerweise tun sie das halt nicht.

Idealerweise überlegst du dir ein Protokoll, wie die das halt, so, und deswegen ist sozusagen diese Aussage, ja, ich fange an, Dinge zu tun, wo ich, du weißt bloß nicht, welcher von denen halt der ist, der nachher das Problem haben wirst.

Und den musst du ausrüsten mit Mechanismen zu sagen, so, okay, ich will jetzt wirklich so weit gefahren, wie ich konnte, jetzt braucht man halt hier, ich brauche hier Verstärkung, irgendwer muss mich abholen.

Und das ist halt genau, dieses Abstrakter gesehen ist halt, du machst dir ein Portfolio, jede Theorie in sich muss schlüssig sein.

Die muss sein, die darf da, die darf der Naturwissenschaftlich nicht widersprechen.

Du musst einen Anhaltspunkt haben, wo du sagst, naja, irgendwo hat sowas in der Art schon mal funktioniert, es ist nicht völlig an den Haaren herbeigezogen.

Auch wenn wir sozusagen jetzt auf dieser Idee so lange rumhauen und so viel versuchen, sie niederzumachen, irgendwie scheint es trotzdem noch irgendwie eine gute Idee zu sein, dann sollte man das jetzt mal ausprobieren.

Und so kommst du halt zu einem Portfolio, wo du mit relativ wenig Aufwand einem zeitlich kurzem Zyklus tatsächlich provozieren kannst, dass dir Feedback von dem Universum gegeben wird, was davon jetzt eine gute Idee ist und was nicht.

Und das ist halt wichtig, weil.

Genau, und aber wichtig an der Stelle auch parallel, weil deine Umwelt ändert sich, während du das machst.

Die Oase-Band, Vater Morgana.

Ja, ja, genau.

Ja, ja, ja, total.

Die ist mir gerade auch irgendwie der Fadenabhang gekommen an der Stelle.

Entschuldigung.

Achso, doch, und du verstehst, und du verschiebst auch die Diskussion weg von welches ist die richtige Lösung, ja, hin zu welche interessanten möglichen Lösungen können wir jetzt hier alle generieren, ohne uns dann zu streiten, wer hier recht hat.

Sondern es geht nur dazu, können wir möglichst viele interessante, ausprobierbare Lösungen generieren.

Eventuell ist nachher die tatsächliche Lösung, die man nimmt, weil dann gibt es eine Technik, die man dann auch ansetzen kann, wenn du dann das durch hast, dann kontrastierst du, was du aus diesen unterschiedlichen Lösungen gelernt hast und kannst mit den realen, praktischen Erfahrungen dann eine neue Lösung tatsächlich generieren.

Und da muss es nämlich nicht sein, welche von den vier Lösungen war jetzt eigentlich die richtige.

Beispiel, um bei der Wüste zu bleiben, keiner von denen ist zur Oase gekommen, aber der Typ, der nach Norden gelaufen ist und der Typ, der nach Osten gelaufen ist, hat gesagt, also als ich fünf Kilometer nach Osten gelaufen bin, habe ich im Norden was gesehen.

Und der andere sagt, ja, als ich fünf Kilometer in den Norden gelaufen bin, habe ich im Osten was gesehen.

Das kannst du jetzt übereinander legen und weißt, aha, in der Distanz nordöstlich ist was.

Keine der konkreten Lösungen war richtig, aber aus beiden Erkenntnissen konnte ich mir die richtige Lösung nachher generieren.

Und wenn man sich aber die ganze Zeit nur darauf versteift hätte, zu fragen, ist es jetzt richtig, nach Norden, Süden, Osten oder Westen zu gehen, hättest du nie den Input gehabt, um dieses Ding im Nordosten zu finden.

Kann ich nochmal kurz noch eine blöde Frage stellen und zwar möchte ich gerne verstehen, an welchen Projekten man diese Methode am besten macht?

Also du hast halt unbekanntes Problem oder du möchtest, also was möchtest du lösen bei dem.

Du hast

ein Problem, das du nicht a priori, also du bist in einer Situation, die so ungeordnet ist, dass du nicht a priori die Lösung festlegen kannst.

A priori ist etwas, da neigen wir deutschen Ingenieure sehr dazu.

Ich kriege ein Problem, ich kenne meine Handlungsweisen, ich laufe meinen Optionsraum ab und ich präsentiere dir nach einer Woche irgendwie die Lösung.

Wenn das nicht der Fall ist, im Komplexen passiert dann typischerweise folgendes, dann kommt der nach einer Woche mit einer Lösung um die Ecke, du implementierst die, sie besteht alle Tests und in dem Moment, wo sie draußen in die Realität trifft, fängt es an, rechts und links zu knarzen.

Und die Reaktion des Ingenieurs war, ja, du hast mir zu eng einen Zeitrahmen gegeben, hättest mich noch eine Woche arbeiten lassen sollen.

Du hast nicht gesagt, ich habe es nicht mehr.

Oder so hast du das gesagt.

So, aber, genau, so, aber aus der komplexen Perspektive wird immer wieder ein komplexes Problem retrospektiv als geordnet mit, ja, ich habe ja nur X vergessen.

Das Dumme ist nur, du kannst dieses X nie a priori bestimmen.

Wenn hättest du ihm noch eine Woche mehr gegeben, hätte es ein Y gegeben, hättest du ihm noch eine Woche gegeben, hätte es ein Z gegeben.

Und das muss man halt umdrehen, weil im Nachhinein kann man es immer erklären.

Nur im Nachhinein, also auf lange Sicht sind wir alle tot und so.

Was du dort halt tatsächlich machen kannst, ist, du kannst, wenn du normalerweise in einem ingenieursmäßigen Ansatz arbeitest, sagen, okay, wir probieren das Problem klassisch über einen Expertenansatz innerhalb einer gesetzten Timebox zu lösen.

Und wenn das nicht geht, dann müssen wir diesen Modus wechseln.

Also so kann man ein Team, was tatsächlich gewöhnt ist, zu sagen, ja, da setze ich hier einmal hin, arbeitet das Ticket ab und kommt dann mit der Lösung raus.

Und wenn du dann diesen Effekt siehst von, ja toll, alles ausdefiniert, alles abgearbeitet, super Code-Qualität, aber es tut nicht, dann solltest du die Frage stellen, gut, dann sollten wir jetzt hier mal vielleicht zwei, drei Varianten in die Breite ausprobieren und gucken, wo wir weiterkommen.

Das ist ein möglicher Ansatz, wie man das machen kann.

Also Engineering sollte sich immer eine Timebox eignen, weil er sucht ja im Prinzip nur aus bekannten Lösungen aus.

Und wenn das Engineering aber anfängt, neue Lösungen zu entwickeln, dann musst du im Prinzip in diesen anderen Modus wechseln.

Das ist das, was man Unknown-Unknowns manchmal nennt, oder?

Die Dinge, die wir nicht wissen, dass wir nicht so.

Nee, das sind die Known-Unknowns tatsächlich.

Nee, nee, das ist ein, wir wissen jetzt schon, da ist etwas, was wir noch nicht kennen.

Ja, okay, wenn du die erste Timebox gemacht hast, dann weißt du, dass es nicht geht.

Aber vorher weißt du es nicht.

Und man kann viel machen, um es abzusichern.

Das sind diese solchen Kohärenztests, eben mit diesem, sind meine Lösungen irgendwie in sich schlüssig?

Widersprechen sie dem heliozentrischen Weltbild, solche Sachen.

Was ich noch spannend finde, ist ein Ansatz, der auch so aus den 90ern fehlverstanden wurde, wo du gerade das Wasserfallmodell meintest, war dieses Rapid Application Development.

Das war so Ende der 90er, das waren so Pascal-basierte Tools wie Delphi und solche Sachen, so Formbilder etc.

Und Dave hatte mit denen tatsächlich was zu tun, der hat eine ganz interessante Story, was eigentlich mit Rapid Application Development gemeint war.

Weil was raus geworden ist, ist auch wieder dieses, ja, ich kann ganz schnell diese Formulare zusammenklicken und habe dann eine fertige Anwendung.

Worum es eigentlich ging, war eine Methodik dahinter und die ist aber aufgrund dieser sehr starken Technikfokussiertheit von, ja, ich habe hier diesen Formbilder weggefallen und das war folgendes.

Das nennt sich ein 88.

Die haben bei der IBM für Kundenprojekte folgendes gemacht.

Die haben vom Kunden vier Leute sich geholt, die die Aufgaben, die die Problemstellung kennen, Abrechnungssoftware irgendwie überarbeiten, ja.

Haben vom Kunden die vier Leute an vier verschiedene Teams bei der IBM rangesetzt, jeweils mit so fünf, sechs Leuten.

Montag früh, haben mit denen gesagt, so welche Features brauchen wir jetzt als allererstes und haben die halt entwickelt in so einem Rapid Application Ding.

Da hast du dann nach einem Arbeitstag so die ersten, so mal eine Tabelle und hast mal ein Formular, dann hast du dies und hast mal jenes.

Das geht relativ zügig.

Dann haben sie diesen Code, und das ist in vier Teams parallel passiert.

Jedes hat für sich gearbeitet und die durften nicht miteinander reden.

Dann haben die ihren Code eingecheckt und aus Europa nach acht Stunden an einen Team in den USA gegeben.

And this team in den USA hatte keinerlei Zugriff auf irgendwelche Formen von Spezifikationen, Kunden oder irgendwas.

Und hat nur die Aufgabe gekriegt von so, hier ist irgendwie Code.

Mach mal weiter.

Haben sich das angeguckt mit, ah ja, okay, alles klar, die machen hier so Abrechnungskram, ja okay, die Formular, ja, das würde ich also nicht machen.

Warte, warte, guck mal, das geht noch besser, das kann man so und so und so machen.

Die haben das wiederum nach acht Stunden abgegeben und jeweils an ein Team in Asien gepackt.

Dann hat sich das Team in Asien das Ding angeguckt, wo jetzt sozusagen die Europeer mit dem Kunden, danach der Army ohne Kunde und dann der Asiate auch nochmal ohne Kunde wieder drauf geguckt hat: von was wollten die hier eigentlich?

Was ist denn das?

Hä?

Okay, das machen wir gar nicht.

Machen wir mal so, so, so und so und so.

Jetzt hast du zum einen drei Kulturkreise durchlaufen, hast unterschiedliche Wirtschaftssysteme durchlaufen, und am zweiten Tag, Dienstag früh, hat deine Anwendung viermal drei Iterationen hinter sich.

Jetzt gucken sich die Europäer das wieder an, was aus ihrem Code geworden ist.

Und das Ganze spielen zu

zwei Wochen.

Dann hast du die Hände über den Köpfen zusammen.

Nein, nein.

Nee, und sagen so, da hätten wir ja gar nicht dran gedacht, dann gehen sie mit dem Kunden, sagen wir, wie verhältst du von XYZ?

Und das haben die zwei Wochen am Stück gespielt, dann hast du dieses Projekt in vier Ausprägungen über 10x3, über 30 Iterationen geprügelt und kontrastierst dann, was ist eigentlich in diesen vier Handlungssträngen rausgekommen, weil die ja auch noch nicht mal miteinander geredet haben über die Zeit.

Und dann setzt du dich hin und fragst so, was haben wir hier jetzt eigentlich gelernt?

Und jetzt kannst du dich hinsetzen und kannst sagen, so, okay, jetzt suchen wir uns heraus, was wollen wir hier eigentlich?

Und das war der ganze Charme von einem Rapid Application Development Ansatz, so einen hochgetakteten Zyklus zu fahren von wie kriege ich eigentlich Erkenntnisgewinn.

Also die Innovationsgeschwindigkeit ist buch dann, ja.

Diese Innovationsgeschwindigkeit brutal.

Das hört sich so ein bisschen an wie das Startup-Modell auf Elf aufgedreht.

Wir machen jetzt vier Sachen.

Aber jetzt müsste ich mal überlegen,

das war Mitte der 90er, aber das war nicht gedacht als ein Modell, was im Dauerbetrieb funktioniert, sondern das war gedacht als ein Ansatz, um unter Möbel, wenn ich habe wenig Information, viel Unsicherheit und muss irgendwie Entscheidungen treffen für ein extrem teures strategisches Projekt, dann ist die Aussage, dann machen wir das jetzt mal zwei Wochen und danach hast du mal so richtig Datenbasis.

Und dafür war Rapid Application Development halt wichtig.

Da ging es nicht darum, ein finales Produkt in der Hand zu haben, was hochpoliert, etc., sondern es war darum, in so einer Materialschlacht, in einer Personalschlacht so schnell wie möglich, so viele Varianten wie möglich zu generieren.

Und das hat mir die Augen geöffnet, weil ich saß ja auch davor und habe in der Uni mit diesen Rapid Application Development Tools so ein Wasserfallmodell irgendwie versucht, übergeholfen zu kriegen.

Und dann hörst du plötzlich von dieser Story, IBM hat ja diese Sprachen mitentwickelt.

Und das war aber dieses zweigleisige Ding von, wir wollen hier diesen Prozess fahren können und dieser Prozess hat es aber nie geschafft, irgendwie mal außerhalb angewendet zu werden.

Und dann bleibt aber trotzdem über mit, na jetzt haben wir so Tools, die können wir ja verkaufen.

Tja.

Ja, das ist halt, wenn man viele Ressourcen hat, kann man da Sachen erschlagen und man muss die dann auch nutzen.

Das kann man aber auf dem Kleinen machen.

Vielleicht ist jetzt irgendwie ein ganzer Zeitpunkt, irgendwie mal das nochmal so zusammenzufassen, was hast du gerade Rapid Application Development irgendwie gesagt.

Es gibt ja noch so mehrere andere Methoden oder Methodologien, die man irgendwie kennt.

Vielleicht können wir aber die ein oder andere nochmal irgendwie sprechen, vielleicht nochmal irgendwie Extreme Programming und oder Scrum irgendwie mal kurz erklären für unsere Hörer, was das eigentlich so ist und wie man das so macht und vielleicht ein, zwei Probleme damit irgendwie aufwachen oder wie ihr das so gerne macht oder das eben auch von Flow-Charts oder was gesprochen, was ist das?

Macht ihr einen Kampan?

Da gab es ja ganz viele verschiedene Methoden.

Ja, vielleicht kann man da irgendwie einmal kurz durchgehen.

Wollen wir mit Scrum einfach anfangen?

Wer kann am meisten erzählen?

Jochen hat da, glaube ich, ganz viele Tipps.

Ich glaube, man muss mit XP anfangen, oder?

XP ist zeitlich früher und Scrum ist dann das nächste.

Ich würde die alle zusammenfassen zu Das ist halt so Agile, genau.

Oh, Jochen, jetzt setzte dich aber ins.

Ich glaube, da so groß sind da die Unterschiede gar nicht.

Also der Spirit ist setzt.

Also für freundliche Zuhörer-Rans bitte Jochen.

Er nimmt die Hate-Mail sehr gerne entgegen.

Wir lassen sie dann von Sarah Bosetti filtern und lesen die Hate-Mail auf geschönt.de.

Also Jochen, dann fast nochmal zusammen, was agile Methoden sind.

Ja, ich würde sagen, das Agile Manifesto ist ja schon irgendwie ein guter Startpunkt.

Das kriege ich jetzt auch nicht so aus dem Kopf rezitiert, aber die wichtigsten Punkte sind halt sowas wie, dass halt irgendwie Interaktion mit dem Kunden wichtiger ist, als irgendwie Pläne zu befolgen, dass halt irgendwie funktionierender Code wichtiger ist, als halt ausführliche Dokumentation.

Kurze Zyklen.

Ja, genau, dass man das irgendwie iterativ.

Ja.

Ich meine, ich kann es kurz vorlesen, ich habe es gerade da.

Das Original sagt also, we are uncovering better, deswegen, da fange ich auch immer wieder an, die meisten überspringen, dass we are uncovering better ways of developing software by doing it and helping others do it.

Through this work, we have come to value individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration, over contract negotiation, responding to change over following a plan.

That is, while there is value in the items on the right, we value the items on the left more.

Und es ist so aktuell eigentlich, wenn ich es halt neben diese industrialisierten Varianten von Agilität halte.

Ich habe es wirklich lange Zeit nicht angeguckt.

Ich hatte es bestimmt zehn Jahre nicht in der Hand und im letzten halben Jahr immer mal wieder rausgeholt.

Es ist aktueller denn je.

Das stimmt.

Da habe ich tatsächlich eine kleine Anekdote dazu.

Ich habe mal, als ich mein Studium fertig hatte, wollte ich gerne noch ein bisschen an der Universität bleiben, deshalb habe ich eine Doktorarbeit angefangen.

Und die Doktorarbeit beschäftigte sich so im Großen mit Projektportfoliomanagement.

Das ist quasi eine Ebene drüber.

Das ist nicht Management eines einzelnen Projektes, sondern Management vieler Projekte.

Also welche Projekte mache ich überhaupt?

Welche sind wichtig, wie priorisiere ich die, in welcher Reihenfolge sind die und so weiter.

Und ich habe relativ lange Literaturrecherche gemacht und habe dann diese Doktorarbeit wieder abgebrochen, als ich ein Projekt, als ich ein Paper gefunden hatte mit dem Titel Are We Getting Any Better?

Comparing Project Management in the Years 2000 and 2008.

Super Paper rate ich jedem zu lesen.

Die kurze Form ist.

Nope.

Sie haben viele Projekte untersucht im Jahr 2000 und im Jahr 2008.

Und wenn man die Leute in den Projekten befragt, dann sagen die, ja, das ist jetzt alles viel besser.

Wenn man aber die Ergebnisse der Projekte anguckt, dann hat sich eigentlich nicht viel getan.

Wir haben die Zufriedenheit erhöht.

Genau, wir haben die Zufriedenheit erhöht.

Das ist ja auch schön.

Aber es ist nicht das, was man eigentlich erreichen wollte.

Und das war für mich so ein bisschen der Punkt, wo ich mir gesagt habe, okay, viele Sachen, die man hört im Projektmanagement und viele von diesen Methodologien, die sind sehr dogmatisch und die sind sehr, ihr müsst es so machen und ihr müsst es so machen.

Und da gehören Scrum und XP absolut dazu.

Die haben sehr, sehr strikte Regeln.

Also es gibt quasi niemanden, der ein echtes Scrum macht.

Es gibt niemanden, der echtes XP macht, weil die einfach so super strikt sind, dass man die pragmatisch nicht befolgen kann.

Ja, also tatsächlich.

Sie widersprechen dem Manifesto auch im Prinzip dadurch.

Ja, natürlich, total.

Also ich würde auch sagen, oft, wenn man sagen Leute dann so, naja, das ist ja nicht so gemeint, dass man das jetzt einfach nur als Regelwerk nehmen und dann einfach blind anwenden.

Ja, aber dann würden dir die Scrum Master widersprechen.

Aber die haben ja auch nicht mehr.

Scrum ist nur, wenn du selber alle Regeln befolgst.

Und du hast ja ein Zertifikat dafür gekriegt.

Ja, natürlich.

Das klingt so, wenn du alle Regeln befolgst.

Wie gesagt, wenn du diesen ganzen Dingen folgst, dann fühlt es sich so an, als ob du viel erreicht hast.

Dann fühlst du dich besser mit deinem Projekt.

Aber das Projekt selber ist dadurch nicht erfolgreich geworden.

Die Projekte, die du machst, sind nicht erfolgreich geworden.

Und das war für mich so ein bisschen der Weg hin zu weniger Projektmanagement, ist mehr Projektmanagement.

Was ja durchaus dem Agile Manifesto auch entspricht.

Und das ist der Punkt, worauf ich raus will.

Das Agile Manifesto ist deshalb immer noch relevant, weil wir Probleme lösen, die weil wir versuchen, Probleme zu lösen, die wir aber nicht lösen.

Wir machen immer mehr Projektmanagement.

In Firmen ist Projektmanagement so ungeheuer wichtig, dass man dem nicht entkommen kann.

Im Endeffekt löst es aber die Probleme nicht.

Aber das ist doch jeder spannend.

Also wir haben jetzt immer noch nichts über die Methoden gesagt, aber das hört sich so an, als wäre Projektmanagement ein gutes Projektmanagement quasi so, du musst dafür sorgen, dass sich die Menschen, die für dich arbeiten, gut fühlen und wohlfühlen.

Dann wird das schon irgendwie.

Nee, überhaupt nicht.

Das ist das, was die Methoden machen.

Das gutes Projektmanagement sorgt dafür, dass die Projekte erfolgreich sind, egal wie die Menschen gehen.

Aber Projekte werden halt von Menschen.

Ich möchte nicht missverstanden werden.

Die Menschen machen ja die Projekte.

Das heißt, du kannst nicht dafür sorgen, dass Projekte erfolgreich werden, zumindest nicht auf lange Sicht, wenn du die Menschen dabei kaputt machst.

The gaming industry would like to differ.

Ja, wobei die ja auch nicht mehr so gut haben.

Ja, auch die machen so langsam auf.

Auch die

herben Rückschläge gehabt.

Genau, da würde ich gerne einhaken, weil das halt auch so ein fundamentales Problem ist, irgendwie, so je älter ich werde.

Also am Anfang, ich war auch sehr, ich war da, ich habe tatsächlich mal irgendwie diese Agile-Geschichte halt in einem Unternehmen, also mit sehr dafür gearbeitet, dass das da umgesetzt wird.

Ich dachte, ja, das machen wir, wir folgen jetzt die Regeln einfach nur alle auf 100 Prozent wie ein XP, dass alles schon gehen.

Und dann in ein paar Monaten funktioniert das ja alles, das hat dann irgendwie ein paar Jahre gedauert und es war ein eher schmerzhafter Prozess.

Und es hat schon irgendwie funktioniert, aber es war alles nicht so rosig.

Und irgendwie älter ich werde, desto mehr habe ich so das Gefühl, es ist nicht so beim Management von diesen Dingen nicht so sehr die Frage, wie man das macht, sondern die Frage, wer das macht, ist auch sehr, sehr wichtig.

Ja, klar,

und das ist auch so ein bisschen das, was da rauskommt.

Du kannst dir ganz viele Regeln ausdenken, aber die funktionieren nicht, weil es halt Menschen sind, die die Projekte machen.

Und du musst dafür sorgen, dass die Menschen, die die Projekte machen, die Projekte erfolgreich machen.

Und das heißt, da ist immer diese menschliche Komponente dabei.

Du musst die richtigen Menschen finden, du musst die Menschen richtig dazu bringen, die Sachen zu machen.

Und dann am Ende, wenn du das geschafft hast, musst du auch noch dafür sorgen, dass du die richtigen Projekte machst.

Ja, es ist nicht so ganz einfach.

Und ich wäre auch, ich bin auch zunehmend pessimistisch, was die Möglichkeit angeht, irgendwie das Verhalten von Leuten irgendwie so großartig zu verändern.

Ich meine, auch wenn man jetzt irgendwie sich zum Beispiel Kinder anguckt und also ich meine, so als Eltern ist man ja wahrscheinlich so in der privilegierten Position, ja, sozusagen, man hat so die Rede, man hat die maximale Möglichkeit, Dinge zu beeinflussen eigentlich.

Also besser wird es nicht.

Also ich glaube, Manager haben wesentlich weniger Zeit, Energie und was sie da reinstecken können, um halt das Verhalten zu modifizieren.

Und selbst bei Kindern, naja, ich bin mir nicht so sicher, ob das gut funktioniert.

Das ist so, ein bisschen kann man schon ändern.

Aber so grundsätzlich, ja, und ich fürchte, wenn man jetzt als Manager die Vorstellung hat, man ändert irgendwie das Verhalten von Leuten grundsätzlich oder macht Leute zu anderen Personen oder das funktioniert einfach nicht.

Ja, das glaube ich auch.

Das glaube ich auch nicht.

Deshalb sage ich ja, du hast diese menschliche Komponente dabei.

Du musst dafür sorgen, dass die Menschen, die du im Projekt hast, die richtigen sind und dass die die Sachen so machen, dass sie sehr

erfolgreich sind.

Es wird immer unterschiedlich sein.

Es wird immer unterschiedlich sein, je nachdem, welche Projektteilnehmer du hast.

Es wird keinen Hamburger Prozess geben, wo hinterher immer der gleiche Hamburger rauskommt.

Und selbst wenn du so einen Prozess findest, dann wird es halt immer der gleiche.

Schlechte Hamburger sein.

Und jetzt bin ich rausgefallen.

Ja.

Ne, ich bin nicht rausgefallen.

Nein, nein, nur so dabei.

Ich müsste mich kurz muten, weil hier mein Drucker angefangen hat, Dinge zu drucken.

Alles klar.

Ich würde aber tatsächlich nochmal reingehen, weil da kann ich tatsächlich noch eine völlig andere Ecke mit reinwerfen.

Das sind die Manager Tools.

Weil da gehen wir jetzt ja weg von Projektmanagement über zu Management allgemein.

Was wir relativ viel benutzen, ist tatsächlich ein Ansatz von, ja, die heißen Managertools.com.

Die haben irgendwie anderthalb tausend Podcasts inzwischen veröffentlicht.

Ja, einmal die sind sehr straightforward.

Punkt.

Es sind so zwei irgendwie Ex-Militärs.

Und die haben aber tatsächlich dieses Thema, wo Jochen und ich eben so ein bisschen kurz aufschreien wollten zum Thema Ja Hauptsache die Projekte sind erfolgreich.

Die haben sich halt diese klassische Management-Theorie relativ gut weiterentwickelt mit der Aufschrift von die zwei Aufgaben des Managers sind Results and Retention.

Und welches ist wichtiger?

Ich versuche gerade rauszukriegen, was der Dominik mehr sagen will.

Du hast de Mikrofon gerade von deinem Mund entfernen und seitdem bist du leiser als vorher.

Entschuldigung, alles klar, danke.

Was ist wichtiger?

Results oder retention?

Nee, nee, nee, das kommt her aus der Industrialisierung.

Da war die Management-Aufgabe tatsächlich Results.

Und stimmt dir dazu?

Genau.

Und das alleine reicht halt eben nicht, weil das halt keine langfristige Perspektive hat.

Und aber auch die Management-Theorie aus Mitte des 20.

und frühen 20.

Jahrhunderts weiß schon, dass eine Organisation halt auch ihr langfristiges Wohl im Auge behalten muss.

Das heißt, du musst die Fehler, die du durch eine reine Result-Orientierung erzeugen würdest, durch eine entsprechende Retention der Personen, die du halt hast, balancieren.

Und das ist dann eben genau die Aufgabe eines Managers, das gut in den Einklang zu bringen, zu gucken, dass dein Team funktioniert und zwar auch Mensch für die Menschen funktioniert, weil ohne die Menschen geht's halt nicht, aber eben mit den Menschen zusammen entsprechende Ergebnisse zu erzielen.

Kannst du vielleicht nochmal ganz kurz definieren, was Retention ist?

Retention heißen, die Leute, die für dich arbeiten, bleiben dir erhalten.

Wenn du nur Results erzeugst, dann verschleißen die Leute, dann gehen sie entweder oder werden krank oder was auch immer.

Das sind halt so, das ist so Industrialisierung.

Ja, wenn die Masse an Arbeitern unendlich ist, an Arbeiterinnen, dann hast du irgendwie.

Ja, genau.

Wenn du genügend Nachschub hast an Jugendlichen, die Burger machen oder an jungen Männern, die Computerspiele machen wollen, dann kannst du es machen.

Und selbst selbst da ist es so.

Selbst bei den Burgern ist es so, wenn du ein eingespieltes Team hast, bist du effizienter und kannst mehr erwirtschaften, als wenn du ein Team hast, was ständig wackelt und wo alle gegen dich arbeiten im Prinzip, weil sie halt irgendwie ihres Jobs nicht sicher sind, etc.

Und diese Balancierung halt bewusst wahrzunehmen als Aufgabe, das hat uns nochmal ganz schön geholfen.

Die bauen da relativ viel Zeug dann drumrum und haben auch viel Guidance für Leute, die sich jetzt so für Management allgemein interessieren.

Wichtig ist auch, das ist halt keine irgendwie mal schön sich ausgedachte Theorie, sondern es ist halt relativ offensichtlich.

Weil wenn Mitarbeiter dir verloren gehen, geht halt Organisationswissen verloren.

Da gibt es auch ganz alte Anekdoten von irgendwie, ich glaube, einer der IBM-Manager war das oder so, wo irgendeiner seiner höherrangigen Angestellten, glaube ich, eine halbe Million Dollar in den Sand gesetzt hat und er gefragt wurde, ob der jetzt endlich gekündigt wird.

Und er guckt ihn dann halt an und sagt, bist du bescheuert?

Ich habe gerade eine halbe Million Dollar für Trainingsprogramm für diesen Mann ausgegeben.

Der hat was gelernt, das gebe ich halt in meinem Wettbewerber.

Bist du blöd?

Und das ist halt tatsächlich, Leute neu reinzukriegen und wissen, neu in die Organisation reinzuholen, ist so unendlich teuer und fragil, dass halt Leute aus einer Organisation loszuwerden oder zu verlieren, ist halt einfach mal, das ist prohibitiv, das geht nicht.

Du musst dich halt darauf einstellen, das ordentlich zu machen.

Tja.

Ja, ich würde auch sagen, ich weiß nicht genau, also ich kann das verstehen, dass man sozusagen dann so Turnover versus Ergebnisse irgendwie vielleicht gegeneinander.

Aber ich weiß gar nicht, ob das so eine richtige Dichotomie, gibt es dafür eigentlich einen deutschen Ausdruck für Falls-Dichotomie.

Keine Ahnung, fällt mir jetzt keiner ein, ehrlich gesagt, weil im Grunde setzt man da ja voraus, dass die einzige Möglichkeit, das Ergebnis zu verbessern darin besteht, halt irgendwie pro bezahlter Stunde mehr Produktivität aus den Leuten zu pressen ist.

Ja, nee, eben nicht.

Es geht eben darum, eben nicht eine Diktomie draus zu machen, sondern es als komplementäre Aufgabe anzusehen.

Ja.

Genau, weil ich denken würde, man kann nämlich auch genau das andere machen.

Man kann halt versuchen, einfach, dass die Leute pro Stunde produktiver werden, das Ziel zu verfolgen.

Und das ist halt eben nicht damit verbunden, dass die Leute langfristig irgendwie, weiß ich nicht, irgendwie in den Überhaupt gehen oder verschwinden oder keine Lust mehr haben.

Du musst es nur in der Management-Theorie musstest als explizites Ziel des Managers machen, weil alles, was du zum Ziel aufrufst, und das ist bei Menschen nun mal so, und deswegen ist auch, da machen wir fast eine Schleife zum Anfang jetzt wieder zurück zum Thema Zielorientierung.

Wenn du einem Menschen ein Ziel gibst, dann wird er das gnadenlos verfolgen.

Gnadenlos.

Wenn du dem Manager sagst, dein Ziel ist Results, Results, Results, und du gibst ihm noch was, was gemessen werden kann, dann wird er den Teufel tun und das Ding optimieren.

So schlimm, dass im schlimmsten Fall sogar der Messwert dich anlügt, aber er hat sein Ziel erreicht.

Ja, du kannst mal eben ein paar Stellen wegrationalisieren im Krankenhaus, dann hast du als Manager noch ein Bonus, weil du hast genau was gespart.

Genau, und dabei geht es sozusagen tatsächlich darum, du musst in der Organisation das Bewusstsein schaffen und auch bei den Leuten, die das tun, dass sie an beidem gemessen werden.

Dass sie sowohl daran gemessen werden, kontinuierlich Ziele zu erreichen und aber ein sozusagen inhärent verankertes Ziel, also das Metaziel ist die Zielerreichung und das zweite Metaziel daran ist aber halt währenddessen die Organisation nicht kaputt zu machen.

Wie macht man denn diese Verantwortung?

Wie schafft man das?

Das ist ja spannend.

Indem du auf die Menschen eingehst, die da drin sind.

Das kommt immer wieder runter auf die Menschen.

Das ist für mich das einzige Ergebnis, was ich aus dieser ganzen Zeit ziehen kann.

Aber wenn ich das

aus dem Firmenperspektive nochmal sehen möchte, wie schaffe ich es denn, dass ein Projektmanager die Verantwortung gegenüber den Menschen wahrnimmt?

Also ich muss den ja irgendwie accountable, responsible halten dafür, was da passiert.

Also messe ich die Retention Rate oder

die kannst du ja einmal.

Das kannst du mal.

Also die gehen halt eher von einem prozessualen Ansatz aus und du solltest halt das Ziel, also das Problem ist sozusagen, wenn du einen Messwert zum Ziel machst, wird er halt gamifiziert.

Das heißt, da musst du immer aufpassen, dass die Feedbackschleife nicht direkt ist, weil dann wird sie halt immer ausgenutzt werden.

Bei den Manager-Tools ist es so, wir haben uns das halt auch angewöhnt, wir haben in der Mitarbeiterführung an der Stelle für einen Manager, der hat drei Werkzeuge, die ihm dafür zur Verfügung stehen und die er zu nutzen hat.

Das eine ist Beziehungspflege über sogenannte One-on-Ons.

Das heißt, jeder Mitarbeiter von uns hat das Recht und der Manager hat die Pflicht, mit jedem Mitarbeiter einmal die Woche ein 30-minütiges One-on-One zu führen.

Da gibt es auch eine entsprechend inhaltliche Struktur, dass der Mitarbeiter auf jeden Fall einmal die Woche zehn Minuten die ungefilterte, ungeteilte Aufmerksamkeit seines führenden Managers hat, der wiederum sich gefälligst vorbereitet und Themen, die arbeitstechnisch, die organisationstechnisch, die vertraglich, die von einer persönlichen Weiterentwicklung abhängen, mit ihm zu besprechen, zu dokumentieren.

Und das ist ganz spannend, weil daraus bei uns nämlich auch, wir haben tatsächlich dann so 75% davon schaffenbar.

Mein Drucker springt schon wieder an, den müssen wir irgendwie rausfiltern.

Und das Spannende ist, aus dieser Struktur raus ergibt sich dann zum einen, ich bin immer verwundert, wenn ich mit anderen Leuten rede, wenn wir fragen, wie oft hast du irgendwie exklusiv mal Zeit mit deinem Chef über irgendwas zu reden, dann ist das häufig relativ wenig.

Und wenn ich dir sage, das machen wir irgendwie jede Woche, dann fallen irgendwie alle irgendwie aus allen Wolken.

Deswegen würde mich auch mal interessieren, wie das bei euch so ist.

Es ist sehr ungewöhnlich, glaube ich.

Also sieht man nicht so häufig.

Und das ist so ein Riesenwerkzeug, weil zum Beispiel sowas wie ein Jahresgespräch ist bei uns kein Jahresgespräch, sondern wird getriggert durch, wann es kommt spätestens nach zwölf Monaten, wenn es dazwischen kein Leistungsgespräch gab.

Leistungsgespräch eine blöde Übersetzung von dem englischen Begriff, den die haben.

Oder wann immer sich in der Rolle, in der Tätigkeit des Mitarbeiters etwas strukturell ändert.

Das heißt zum Beispiel, nach sechs Monaten, wenn deine Probezeit vorbei ist, triggert das halt automatisch, dass man sich halt dann alle O3s einmal anguckt, nochmal durchschaut, was war denn so, worüber haben wir gesprochen, wie hat sich das entwickelt, etc.

Und da muss auch niemand irgendwie was groß vorbereiten.

Da kommen so ein paar Sachen, irgendwie Eckdaten, vielleicht nochmal ein bisschen Gehaltsverhandlungen oder sowas.

Das ist eine Ebene, wo wir sagen, dass ein Manager hat halt die Pflicht, aktiv die Beziehungen zu seinen Mitarbeitern zu pflegen und auch den Mitarbeitern Gelegenheit zu geben, ständig mit der Organisation in Austausch zu treten über den Mitarbeiter.

Das nächste sind Coaching-Ansätze, damit der Manager halt, wenn man im U3 identifiziert, hey, an irgendwelchen Sachen hapert es hier ständig, du hast entweder Konflikte mit irgendeinem Mitarbeiter oder du kriegst irgendwie ein bestimmtes Arbeitsthema geht nicht.

Dann gibt es dafür eine Coaching-Struktur und es gibt eine Feedback-Struktur, um Mitarbeiter tatsächlich geordnet und freundlich und höflich darauf hinzuweisen, wenn irgendwie Verhalten, was sie an den Tag legen, weil Ergebnisse erziehen ist nachher nichts anderes als die Summe des an den Tag gelegten Verhaltens, darauf hinzuweisen, dass irgendwas halt jetzt der Organisation eher hilft oder eher nicht hilft, um sich dann damit halt auseinanderzusetzen.

Und die drei Maßnahmen sind tatsächlich was, das haben wir von den Manager-Tools mehr oder weniger eins zu eins übernommen, wo wir sagen, ich habe nichts studiert in Richtung Management, aber das ist Zeug, wo wir auch von den Mitarbeitern und von anderen immer wieder Feedback kriegen von, Fakt, das ist eine gute Struktur und Idee von, man lässt das nicht einfach so laufen, sondern da kommen sinnvolle Sachen bei raus in Richtung Retention und Organisationsentwicklung.

Was ist ein O3?

Ja, ein One-on-One.

Das ist dieses halbe Stunde jede Woche.

Drei O One-on-One.

Okay.

Und ich habe hier so Stapel von Mitarbeitern, da habe ich jetzt irgendwie seit sechs Jahren jede Woche, fast jede Woche, irgendwie mir die Notizen gemacht, wie wir miteinander arbeiten, was da so anliegt und etc.

Was hat denn denn dann so eine halbe Stunde jede Woche?

Na, die ersten zehn Minuten, da gibt es, also die haben so ein Formular, das liegt bei mir auch immer griffbereit für, wenn man es mal braucht.

Da schreibe ich mir dann halt auf, okay, mit wem rede ich gerade, was ist heute ein Tag.

Und dann hat er 10 Minuten, da stelle ich mir auf der Watch dann so einen Timer von, so, das sind deine zehn Minuten, erzähl mir was.

Und dann kann er mir was erzählen, ob er seinen Garten umgegraben hat, wie es im Urlaub war, oder ob irgendwie gerade irgendwie da Fuß wehtut oder ob das letzte macOS-Update ihm irgendwie die Haare auf den Kopf frisst.

Das sind seine 10 Minuten.

Da quatsche ich dann normalerweise auch nicht dazwischen, außer er bittet mich drum.

Da mache ich mir seine Notizen.

Dann habe ich nochmal zehn Minuten, wo ich ihm Updates gebe über bevor wir im Team Entscheidungen kommunizieren, ist es auch so, dass jeder Manager vorher mit jedem Einzelnen diese Änderungen bespricht oder Neuigkeiten aus der Organisation.

Bei uns gibt es einen Grundsatz, der sagt, in Meetings gibt es keine Überraschung.

Wenn im Meeting irgendwas verkündet wird, wo es Überraschung ist, ist es mehr so, im Meeting hören das alle nochmal im großen Kreis und man guckt sich in die Augen und sagt, ja, das ist jetzt das, was hier passiert, aber in dem Moment ist es nicht ein, oder habe ich ja noch nie davon gehört.

Das geht einfach nicht.

Im Meeting werden auch Entscheidungen nicht herbeigeführt.

Im Meeting wird im Prinzip nur von allen dokumentiert mit, ja, wir haben diese Entscheidung wahrgenommen.

Die soziale Magie ausgeübt, die das dann, die diese Konstruktion Wirklichkeit werden lässt, ja.

Richtig, genau, genau.

Da haben wir noch einen separaten Prozess dazu.

Wir drucken dann so Bilder aus den Stempeln, die dann halt, wo jeder halt so einen kleinen Figurenstempel und committet sich da in, wenn man da draufstempelt.

Genau.

Und das letzte ist dann halt die Frage: Was brauchst du noch für deine persönliche Weiterentwicklung hier im Unternehmen?

Wo fehlt es her, wo geht die Reise hin?

Da gibt es auch ein paar unterschiedliche Prompts auf dem Formular, damit man halt weiß, okay, das immer mal aufzufrischen, immer mal neue Perspektiven einzunehmen, dass man mal guckt, okay, wie sieht denn deine To-Do-Liste geradeaus?

Ist sie zu lang, kommst du klar?

Oder dass man halt fragt, wie sieht es denn aus, wie sieht das nächste Quartal bei dir aus, wie war denn das bei dir mit dem Hausbau?

Dass man tatsächlich wirklich auch, der Arbeitstag ist stressig, man kann sich so ein Kram nicht in jeder halben Stunde neu ausdenken.

Da gibt einem das halt einfach tatsächlich so ein bisschen Struktur, dass man so alle Bereiche, die man mit Leuten halt, mit denen man ständig zu tun hat, auch regelmäßig abklopft, auch wenn es mal ein bisschen mehr und viel wird und man es dann nicht halt runterfallen lässt.

Also auch sehr persönlich dann, das ist wichtig, ja.

Spannendes.

Das ist sehr persönlich an der Stelle, weil das ist ja, das erlebe ich auch immer wieder, wenn du dann solche Situationen hast, dass ein Unternehmen vor großen Herausforderungen steht und Corona ist da für alle von uns mit extrem hoher Unsicherheit versehen von wo geht hier was, wie weiter, wo kann im nächsten Jahr, wenn die zweite Welle kommt oder sowas sein, dann bin ich froh, wenn ich weiß, dass im Unternehmen zu allen Mitarbeitern halt eine gute Beziehung besteht, auf der man solche Herausforderungen tatsächlich in solchen Rahmen auch gut diskutieren kann.

Weil das ist nachher das, wo ich dann sagen muss, da kann ich mich, ich kriege ein besseres Gespür, wie ich mich darauf verlassen kann, wer arbeitet wie, wer hat wo welche Herausforderungen persönlich gerade, wer ist wo mental wie gefordert.

Und das sind ja, wie Johannes halt meinte, am Ende geht es um die Menschen, die diese Aufgaben erledigen müssen.

Ich kann im Projektmanagement die Leute ja nicht als austauschbare Ressourcen behandeln.

Und ich habe Kunden, da kriege ich dann manchmal die Krise, die habe ich mich die Kunden momentan.

Keiner meiner Kunden muss sich angeporen fühlen.

Aber ich hatte in der Vergangenheit Kunden, die haben.

Die hatten alle schon mal solche Kunden.

Ja, die haben tatsächlich angerufen.

Ob ich dann in den nächsten vier Wochen noch drei Ressourcen für sie hätte.

Ja, nee, habe ich nicht.

Nein, Entschuldigung, das klingt wirklich so.

Also wer Menschen als Ressourcen betrachtet, der verheizt sie dann auch.

Ja, und das ist tatsächlich, und ich glaube, wenn man, wenn man schon von Organisation sowas wie Führung von dem Ende her denkt und so angeht, dann erledigen sich auch so diverse andere Probleme aus dem Projektmanagement.

Ja, was du halt versuchst irgendwie im Projektmanagement zu erschlagen, eben durch auch es egal zu machen, wer jetzt eigentlich Dinge tut oder wie viele Leute und ja, es ist halt, du kannst es halt nicht alles voneinander trennen.

Das war jetzt irgendwie ein sehr langer Braindump, sorry.

Ich glaube auch, dass da so ein bisschen das Wort einfach falsch ist.

Man spricht ganz viel über Projektmanagement und tut ganz viel so, als ob die Projekte diejenigen wären, die da gemanagt werden.

Aber im Endeffekt ist es ja nicht die Projekte, die gemagt werden, sondern das sind ja die Menschen, die gemanagt werden.

Idealerweise werden die nicht gemanagt, weil Managen hört sich halt so ein bisschen an, wie so die Ressourcen oder die Kühe, die im Stall sind, die auch schon.

Sondern es ist schon so ein bisschen ein Element von Führung.

Man muss die Leute abführen, anführen, dazu das zu tun, was richtig ist und was notwendig ist.

Wobei Leute, die können das ganz beeindruckend gut und die erreichen alle ihre Ziele, die sie haben wollen und die Leute bleiben alle dabei und die würden alle voneinander durchs Feuer gehen.

Und es gibt Situationen bei Kunden, wo die Menschen halt als Ressourcen bezeichnet werden und dann verhalten die sich halt auch wie Ressourcen.

Die verhalten sich halt wie der Esel im Stall und sagen, ja, da ist jetzt ein Problem, aber das ist ja zum Glück nicht mein Problem.

Und das geht mal eine Weile gut und in großen Firmen geht es auch erstaunlich lange gut, aber die irgendwann werden auch die aufgegessen von den Teams, die das besser können.

Ja, ja, tatsächlich, also ich glaube, dass zum Beispiel ein wichtiger Punkt dabei ist halt so etwas wie die Qualität auch der Dinge, die dann halt, also der Ergebnisse, die halt erzeugt werden, ist halt irgendwie für die Leute, die das machen, ganz wichtig, weil das halt eine Quelle sein kann für warum tut man das überhaupt, ne?

Hat das irgendeinen Sinn?

Weil selbst wenn das jetzt irgendwie am Markt scheitert oder so, wenn ich das Gefühl habe, ich habe da irgendwas gebaut, irgendeine coole, ja, ein cooles System oder ein Ding, was halt was Tolles tut, dann ist das unter Umständen eine sinnvolle Erfahrung, auch wenn das jetzt am Markt vielleicht irgendwie nicht funktioniert oder so.

Und der Markt, wenn man den Markt das überlässt, das zu steuern, dann ist es oft so, dass man quasi als jemand, der das beauftragt oder entwickeln lässt, halt eine gerne Qualität gegen Zeit oder Kosten tauschen würde.

Weil man sagt, naja, also den Effekt, dass ich durch eine geringere Qualität das am Markt ein bisschen schlechter verkaufen kann, der ist lange nicht so stark, wie die Kosten, die ich sparen kann.

Oder lange nicht so stark, wie ich die Zeit.

Das Problem dabei ist halt nur, dass man damit das langfristig kaputt macht, genau.

Und es funktioniert einfach nicht.

Und tatsächlich ist es wahrscheinlich besser, irgendwie auf die Qualität zu gehen und zu sagen, okay, langfristig erhöhen wir die Produktivität darüber, dass die Leute halt einfach ihre Profession so beherrschen und das halt können, was sie da machen, dass sie da halt besser sind als andere, die da halt sozusagen immer am Limit arbeiten.

Es stimmt halt auch da würde ich.

Es stimmt halt auch einfach nicht.

Es gibt viele Beispiele von Produkten, die sehr viel konnten und sehr schlecht und die einfach nicht angekommen sind.

Und es gibt auch umgekehrt sehr viele Beispiele von Produkten, die sich halt auf eine Sache reduziert haben und da die Qualität modsmäßig rausgeholt haben und die in einer ungeheuer schnellen Zeit reingetan haben, die dann sehr erfolgreich geworden sind.

Und ich glaube, dass das der zweite Weg ist, der im Projektmanagement oft einfach übersehen wird.

Anstatt, dass du viele Sachen schlecht machst, kannst ja auch wenige Sachen gut machen.

Und hast dann trotzdem weniger Zeit verbraucht.

Und wenn das die richtigen Sachen sind und wenn du die richtig gut machst, dann kommen die raus.

Gmail ist da so ein Beispiel.

Das konnte am Anfang gar nichts, aber es hat ja halt ein super gutes Interface, so wie die Leute das haben wollten.

Und das hat ja null.

Ja, und einen Gigabyte Platz gehabt.

Okay, gut, das ist natürlich eine Eigenschaft, die ist sehr schwer nachzustellen, wenn man noch in Megabyte denkt.

Aber die haben sich einfach auf diese Kernfeatures konzentriert und haben die so exzellent gemacht, dass die fehlenden anderen Features völlig egal waren, weil die Kernfeatures schon da waren.

Und da ist dann eben die Qualität drin in diesem kleinen Bereich, der dann überzeugt, auch das kennt man unter dem, äh, unter einem bekannten Wort und das heißt halt hier MVP, Minimum Viable Product, macht die Sachen so gut, wie sie sein müssen, dass der Markt die akzeptiert, aber nicht mehr.

Ja, aber das ist ja eben nicht Qualität unbedingt.

Doch.

Weil du halt eine kleinere Menge hast und dort bringst du die akzeptable, also das würde ich nicht unterschätzen.

Akzeptable Qualität heißt nicht scheiße.

Genau, die notwendigen Bedürfnis erfüllst du ja gerade, ne?

Die gerade so notwendigen, dass das genau deinem Bedürfnis befriedigen kann.

Genau, genau.

Und es geht ja auch daran, deswegen, ich würde dort auch, auch da würde ich wieder aus Komplexitätsperspektive für eine flexiblere Sichtweise plädieren.

Wenn ich zum Beispiel fünf Experimente gleichzeitig mache, dann will ich die Qualität runterschrauben.

Dann will ich die Qualität gerade so haben, dass ich möglichst schnell eine Info kriege, ob ich überhaupt in die richtige Richtung laufe.

Wenn ich noch gar nicht mal weiß, ob das, was ich baue, überhaupt Sinn hat oder überhaupt funktioniert, lohnt es sich nicht, von vorne bis hinten irgendwie alles durch zu polieren.

Im Gegenteil, das ist verschwendete Zeit, weil dann kriege ich die Info nicht und das Geld, was ich hätte, um es eigentlich richtig zu machen, ist dann weg.

Das ist auch, manchmal, wenn ich mich mit jemandem reibe, der eher aus dieser Ingenieursdenke kommt, dann gibt es manchmal diesen blöden Spruch, der mir in den Kopf kommt.

Das ist dieses, there's always time to do it twice, but never to do it right.

Und es ist halt bullshit, weil es voraussetzt, dass das, was ich einmal richtig mache, das richtige ist, was ich mache.

Und dann habe ich mir aber halt tatsächlich dann sowohl die Zeit als auch das Geld verballert, anstatt halt noch ein, noch ein Knochen versucht zu haben, oder eben erstmal was halbes zu bauen, um dann ihm zu gehen, ja, jetzt war's richtig und jetzt, jetzt gehen wir hier volle Kanne rein.

Also deswegen da so ein so ein flexibleren Ansatz, um dieses Dreieck, ist ja eben auch nicht gedacht von, ja, es muss alles, man muss sich als Unternehmen oder als Projekt entscheiden, ob dieses Dreieck jetzt auf Zeit, auf Qualität oder auf Funktionsumfang achtet.

Sondern die Frage ist eher, was ist denn heute gerade unser Fokus, um dann zu wissen, okay, wenn wir uns jetzt auf Funktion konzentrieren wollen oder auf Zeit, also wir wollen uns auf Zeit konzentrieren, um schnell Ergebnis, dann wissen wir, wir müssen Abstriche bei Qualität und bei Funktionsumfang machen.

Manchmal muss man einfach auch noch was raushauen.

Ja, und jetzt kann ich aber eine bewusste Entscheidung draus machen.

Das ist ein Werkzeug, um Entscheidungen zu treffen und nicht ein Ding, um sich da vorzustellen, zu sagen, das ist halt so.

Ja, was leite ich denn daraus ab, wenn ich sage, jetzt muss ich weniger Qualität machen?

Ja, also over-engineert kann auch ein Nachteil sein, glaube ich.

Also ich glaube, Qualität, ich weiß nicht, das ist für einen persönlich als Entwickler wahrscheinlich sehr wichtig und halt für Retention irgendwie.

Aber so in so einem Projekt, wenn ich jetzt dafür sorge, dass das alles super funktioniert, aber vielleicht nicht mehr so variabel oder flexibel ist, sondern so schnell austauschbar ist, dann mache ich mir vielleicht auch Probleme, die ich merke.

Qualität ist

ein sehr flexibler Begriff.

Das macht nicht nur, dass es alles schnell gut ist, sondern das bedeutet, dass es so nicht sein soll.

Ja, definitiv, ja.

Genau.

Die ich zum Beispiel für mich aus Operations-Perspektive bedeutet Qualität zum Beispiel, dass ich möglichst viele Dinge, möglichst ohne mir Gedanken zu machen habe, einfach wegschießen kann und die kommen danach halt schon irgendwie wieder.

Das ist für mich ein Qualitätsaspekt.

Wenn ich aber gerade erst evaluiere, ob das Zeug inhaltlich überhaupt sinnvolle Dinge tut, nein, dann brauchst du es noch nicht so weit gebracht zu haben.

Wichtig ist aber eben zu sagen, man weiß, dass Code halt flexibel ist.

Und ich glaube aus einer, viele Leute fallen ja auf die Sunk Code Fallacy rein.

Also dass nur weil ich in etwas schon Zeit und Geld gesteckt habe, darf ich jetzt nicht aufhören, noch Zeit und Geld reinzustecken.

Oder im Gegenteil, ich darf es nicht wegwerfen, ist halt noch viel schlimmer.

Und der Trick ist aber, Code ist zum Wegwerfen da.

Code ist immer, steht immer zur Disposition.

Ich tue mich da auch schwer, weil wenn ich mal schön Code geschrieben habe, dann will ich nicht, dass der weggeht, weil das ist mein Code.

Nein, nein, nein, das machen wir alles ganz anders.

Ja, genau, genau, genau.

Ich habe den Code mal umformatiert.

Ah!

Jede Zeile neu committed, damit auch die History weg ist.

Ja, genau.

Und den Hilfsmittel.

Code ist immer nur das Hilfsmittel, um zu ermitteln, um auszudrücken, was ist gerade unser Verständnis von, wie soll das hier alles funktionieren.

Und da muss ich ihn halt wieder aufreißen, wenn ich festgestellt habe, der war jetzt so falsch.

Und ich mache es aber tatsächlich so, da geht es dann halt sehr weit runter in diesen ganzen Code as a craft zum Beispiel.

Abstraktion kommt bei mir wirklich erst, wenn ich weiß, was ich überhaupt tue.

Ich bin sogar beim Refactoring so, dieses Dry-Prinzip mit Don't Repeat Yourself, das hat eine Falle.

Viele Informatiker und Ingenieure meinen, das bedeutet, wenn ich etwas das zweite Mal aufschreibe, muss ich es verallgemeinern.

Und das Problem ist, du kannst es auch mathematisch betrachten, als Verallgemeinerung ist eine Extrapolationsfunktion.

Und von je weniger Datenpunkten ich extra poliere, desto falscher extrapolier ich.

Und im Prinzip, wenn ich halt anfange, während ich die zweite Instanz eines Coach-Slips schreibe, der sehr ähnlich aussieht wie der erste, und dann schon abstrahiere, dann extrapolier ich im Prinzip von einem Datenpunkt.

Das kann halt alles sein.

Das ist dann aber Jagd.

Ja, genau, das kann man gut als Gegengewicht machen.

Und ich habe mir angewöhnt, frühestens beim dritten Mal, wenn ich irgendwie so einen Chunk von 5, 6, 7, 8, 10 Zeilen wiederhole, ich frühestens beim dritten, eher beim vierten Mal dann zu gucken, was ist denn hier wirklich eigentlich das, was hier gemeinsam ist.

Und ich schreibe es ganz bewusst auf.

Und ich muss mich mal einfach dazu prügeln und sagen, nein, du schreibst es jetzt nochmal auf.

Fängst du noch nichts an zu abstrahieren?

Ja, das hat

ja auch eine gewisse Freude, wenn man so eine Abstraktion gefunden hat, egal ob man die dann nur einmal aufruft oder viermal.

Das ist da so ein Problem da drin.

Ich mache das gerne, ja.

Ich schreibe gerne eine Funktion, die alles kann und die alle Parameter hat.

Die an genau einer Stelle aufgerufen wird mit konstanten Parametern.

Ja, ja.

Ja, es ist ein bisschen.

Auch das sind ja Entscheidungen, die sich dann nachher eher auch unflexibel machen.

Weil, wenn du das dann wieder umbauen willst, musst du plötzlich die Abstraktion wieder ausbauen und das ist auch was, das passiert viel seltener.

Ja, genau, ja genau.

Und es ist halt, und deswegen ist Erweiterbarkeit, Code, der nicht existiert, ist am allererweiterbarsten.

Ja, wobei ich sagen muss, es gibt auch wieder, aber es ist halt nie so einfach.

Es gibt auch wieder das Gegenteil.

Also was mir zum Beispiel tatsächlich, also dieses, man, also wenn man, ich habe das manchmal, wenn ich so auf Code gucke und denke mir so, nee, das muss irgendwie anders sein, dann hat man nicht, dann mache ich das jetzt nicht so, dass ich irgendwie darüber nachdenke, quasi, ja, ich zeige mir nicht Essen-Diagramm, sondern es ist so ein gewisses ästhetisches Gefühl.

Das ist so wie, weiß ich nicht, wenn man Musik macht oder einen Satz formuliert oder so, dann fühlt sich das manchmal richtig an und manchmal nicht.

Und diese ästhetische Komponente kann einen auch dazu bringen, überhaupt erst ein Problem auf eine sinnvolle Art irgendwie anzugehen.

Also das habe ich auch oft, dass mich sozusagen meinen Sinn für Ästhetik irgendwie dann zu einer Lösung führt, wo ich sie am Anfang gar nicht gesehen hätte, sondern ich habe nur aus ästhetischem, aus einer ästhetischen Motivation heraus irgendwas umgestellt und dann stelle ich plötzlich fest, irgendwann so, ach, das löst das Problem ja.

Und insofern kann auch irgendwie reine, so, ich meine, ohne dass man jetzt vorher schon weiß, wohin das führt, irgendwie ästhetisch motivierte Code-Um-Formatiererei, die kann einen natürlich auch ins Verderben führen, das stimmt.

Oder halt zur Lösung, tja, keine Ahnung, was man da sagen sollte.

Das ist die Tagline dieser Episode, oder?

Es ist alles nicht so einfach.

Das Spannende dabei ist aber ja zum Beispiel, du aktivierst damit halt eins deiner kognitiven Systeme, gerade halt eher so das auf Pattern Matching basierte, wo du halt eben nicht eine kausal hergeleitete Kette hast, von warum du jetzt diese eine Änderung führst, sondern du sagst, irgendwann mein Bauchgefühl ist komisch und das ist ja der Teil von, das ist der Craftsmanship.

Also ein guter Handwerker, der viel Erfahrung hat, der kann dir manchmal noch nicht genau sagen, warum das jetzt eine schlechte Idee ist, aber wir machen es jetzt mal anders.

Und in dem Moment, wo er dann fertig ist, er genau da drüben, das da.

Das kann er dir aber vorher nicht sagen und das Bauchgefühl und die Erfahrungen sind aber wertvoll.

Und er wird natürlich währenddessen beobachten, ob seine Schleife, die er da gerade dreht, jetzt tatsächlich richtig ist oder nicht.

Der wird auch wieder zurückgehen und sagen, nee, ach Mist war jetzt irgendwie falsch.

Und wichtiger ist aber eben, das ist ja genau diese Art von Flexibilität, um der es bei der Agilität ja auch geht, um dieses Responding to Change.

Du gehst mit einer Annahme da rein, fängst an zu arbeiten, stellst fest, nee, so nicht, ach doch so, aber nee, jetzt eher hier drüben.

Also ein Freund von mir hat halt auch so einen Projektablaufplan immer wieder mal für Kunden.

Das ist ein relativ bekannter Comic, wo du sagst, wo ist unser Startpunkt, wo ist unser Zielpunkt?

Und die meisten Leute denken halt, du läufst jetzt diesen geraden Weg von A nach B ab.

Der ist aber, und so funktioniert, so versucht auch viel Projektmanagement zu sagen, so, wir sortieren das jetzt alles mal so, dass wir diesen Weg hier gerade durchlaufen können.

Das Problem ist nur, wenn man das als eine Landschaft betrachtet, so als so eine Karte von wie du dich in der Welt orientierst, dann ist dieser Weg nicht unbedingt sinnvoll, weil dazwischen sind irgendwie drei Sümpfe mit Alligatoren und ein riesengroßer Berg und eine riesengroße Schlucht.

Und um das irgendwie, um das so zu queren, ist völlig bekloppt und es wäre viel einfacher, erstmal ein bisschen nach links zu laufen, dann nach oben und siehe da, hier ist ein Aufzug, aha, und hier ist eine Straße und da ist ein Taxiservice und jetzt muss ich schon da.

Und deswegen sieht ein Projekt halt manchmal eher so aus, dass man halt so, oh, tausend Schleifen und rechts und links.

Und das ist aber tatsächlich der in Summe energetisch bessere Weg, als zu versuchen, es von vorne nach hinten durchzuprügeln mit so einem abgeschlossen definierten Punktweg.

Ein großes Abenteuer auf einer Landkarte.

Kompass ist kaputt, ja.

So sind Projekte.

Ja, genau.

Ja, und man darf das halt nicht wegmachen.

Ich glaube, der Fehler im Projektmanagement ist, wenn man versucht, das wegzumachen, dass das nicht passiert.

Weil dann fehlen dir diese ganzen eigentlichen Erkenntnisse da drin.

Ja, ja, und das wird aber oft dann versucht, ne?

Man sagt halt so, irgendwie, die Karte ist das Gebiet und dann, ja, ja.

Ja, weil wenn er halt erwartest, dann holt man halt den großen Bohrer an, dann geht man halt durch, ne?

Also auch hier wieder nochmal, also ich muss selber ein bisschen korrigieren.

Wenn du in einem bekannten, in einer bekannten Domäne arbeitest, ist das legitim.

Wenn deine Aufgabe ist, du sollst von A nach B.

Und der Deal ist, du befindest dich in Deutschland, in München und sollst mit dem Auto nach Berlin fahren, dann holst du halt nun mal die blöde Karte raus, guckst, wo die Autobahnen sind, guckst, wo der Stau ist und dann fährst du halt.

Wenn aber die Aufgabe ist, wir wollen heute ein schönes Picknick machen, da drüben ist eine Wiese, wo ist denn hier der schönste Punkt auch zum Picknicken, dann kann ich halt die Karte nicht rausholen.

Dann muss ich anfangen loszulaufen.

Und dann kann ich mich nicht nur auf den bekannten Wegen bewegen und dann ist mein Werkzeug auch ein anderes.

Dann muss ich irgendwie mir die Gummistiefel anziehen und damit rechnen, dass hier irgendwie noch irgendwo plötzlich ein Schaf um die Ecke kommt und ein Hund und ich irgendwie in ein Loch trete.

Das ist halt was anderes.

Da brauche ich halt Regeln und Verhaltensweisen, die erlauben, mich in unbekanntem Gebiet zu bewegen und mich darauf einzustellen, was hier eigentlich gerade passiert.

Und das ist kategorisch anders, aber eben situationsabhängig, legitim oder auch nicht.

Also aber bekannte Probleme kann man ja anscheinend dann doch mit einem Wasserfall erschlagen.

Natürlich.

Ja, aber wenn es ein bekanntes Problem ist, warum entwickelt man dann Software, damit man einfach irgendwie, keine Ahnung, was ist.

Warum dann Software neue, die gibt es ja dann schon.

Die gibt es ja dann schon.

Ja, genau.

Im besten Fall.

Also ja, also auch da kann es Gründe geben, die alte Software ist zu alt, im Sinne von der Compiler kannst du mehr, die Firma ist weggesetzt.

Und aber dann kannst du es aus dem Angehen.

Dann kannst du auch sagen, wir setzen uns jetzt hin, wir programmieren es jetzt nochmal so runter.

Ist ja kein Problem, dann macht man das halt.

Es gibt ja auch Ansätze, die sagen, du sollst halt zwei machen.

Musst halt zweimal machen.

Das erste Mal weißt du noch nicht, wie es geht, und beim zweiten Mal weißt du halt, wie es geht und deshalb musst du es zweimal machen.

Ist auch eine legitime Methode.

Nur da verlierst du halt das, was der Christian die ganze Zeit schon sagt.

Meistens weißt du ja gar nicht, wo du hin willst.

Oder meistens weißt du ja gar nicht, ob das der richtige Ort ist, an dem du gehst.

Meistens weißt du gar nicht, ob es diese Lösung gibt, die du haben möchtest.

Auch wenn du sie erreicht hast, weißt du nicht, ob es die gibt oder ob es die richtige ist.

Und es dann nochmal zu programmieren, macht dir sicherlich, oder nochmal zu entwickeln, macht sicherlich das Produkt besser, aber ob das das richtige Produkt ist, weißt du dann immer noch nicht.

Ja, auch ein schönes Phänomen, auf das man dann halt irgendwie so in der Praxis auftrifft, ist dann irgendwie, ich weiß nicht, ob das jetzt, aber das ist da auf jeden Fall auch nah dran, irgendwie Second System irgendwie.

Oh ja, das ist

dann der Gegenteil.

Wenn du es beim zweiten Mal machst, dann baust du alles ein, was du dir beim ersten Mal ausgedacht hast.

Und da kommen ja die agilen Methoden halt im Prinzip ins Spiel, dass du eben nicht sagst, ich mache da Second System draus, sondern dass es halt im laufenden Projekt diesen Modus wechseln kannst und ganz so, weil wir Unitests haben und weil wir dies haben und weil wir jenes haben, weil wir mit unserem Code flexibel umgehen und weil es Common Code Ownership ist.

Deswegen können wir jetzt den Code, in der vielleicht noch nicht Qualität, wie wir sie haben wollen, im laufenden Betrieb sukzessive umbauen.

Und das halt, aber Komplexität erfordert auch einen granularen Blick auf die Welt, dass du halt immer wieder mal kleinere Einheiten, größere Einheiten anguckst und dann zu sagen, so, das Subsystem da drüben hat sich jetzt stabilisiert, da räumen wir die Qualität jetzt auf, da drüben experimentieren wir noch.

Es muss halt keine Blanko-Entscheidung für alles sein.

Ja, gleichzeitig kannst du aber auch das Ziel nachführen.

Das ist so ein so dieser andere Aspekt der agilen Entwicklung, dass du zwar die Software, die du entwickelst, so gut wie es geht entwickelst, aber dass der erst nach und nach rausfindest, was du überhaupt für Software entwickeln musst, was du überhaupt erreichen möchtest.

Und das kannst du natürlich nur dann nachziehen, wenn du die Flexibilität hast, das Ziel zu verändern.

Wenn du die Flexibilität hast, zu sagen, okay, der Plan, den wir uns zurechtgelegt haben, das ist der perfekte Schlachtplan und den können wir so durchziehen, aber der bringt uns nichts.

Dann haben wir hinterher ein Produkt, was egal ist.

Und das findest du raus, während du es machst.

Das findest du raus, wenn du es released hast.

Und deshalb sind da diese ganzen Sachen drin.

Release early, release offen, ja.

Break Things, Fail Fast, diese ganzen Sachen, die sind nicht dafür da, um die Qualität des Produktes zu verbessern, sondern die sind dafür da, den Product Fit zu verbessern.

Die sind dafür da, ein besser passendes Produkt zu finden, was du vorher nicht wissen kannst.

Du kannst vorher nicht wissen, was der Kunde haben möchte, wenn du es nicht ausprobiert hast.

Selbst wenn du selber der Kunde bist, kannst du es nicht vorher wissen.

Und das ist uns allen schon mal so gegangen, dass wir uns überlegt haben, oh, da muss ich jetzt eine Library für irgendwas schreiben.

Und dann hast du sie geschrieben und hast gemerkt, das ist ja ein Quatsch und hast sie weggeschmissen und hast nochmal neu angefangen und gemerkt, ich brauche was anderes.

Wie war einstellen, dass der sagte, wenn wir wüssten, was wir tun, wäre es keine Wissenschaft.

Und ist jetzt tatsächlich spannend, weil wir halt jetzt in einem Feld sind, wo man das halt, dieses, wir wissen eigentlich nicht, was wir tun, aber wir haben halt Handwerkszeug und wir können das operationalisieren, wir können das halt im laufenden Geschäft machen.

Das ist total merkwürdig.

Wir sind jetzt an einem Punkt, wo ich halt sagen kann, ja lieber Kunde, ich baue dir jetzt da halt auf Systemebene, auf einer Infrastrukturebene noch irgendeine neue Lösung ein und ich liefere dir, und zwar jetzt in einer halben Woche mal hingestrickt und dann nehmen wir das live in Betrieb und dann hast du da irgendwie 99,5% SLA auf diesem Ding drauf mit Garantie.

Weil ich weiß, dass wir ausreichend flexibel sind, ausreichend kleine Änderungen haben und das ganze Handwerkzeug halt eben belastbar ist.

Wer würde denn heutzutage irgendwie ein Haus kaufen?

Ich habe jetzt, also bauen, ich habe jetzt ja gerade saniert, wo der Dachdecker sagt, ja, ich baue dir das jetzt erstmal hin und dann müssen wir ein halbes Jahr lang warten, ob es zusammenstürzt oder nicht.

Und der ist halt in der Lage, mit seinem Handwerkzeug zu sagen, während des Projekt, der war einfach sehr gut, der Dachdecker hier.

Währenddessen man hier halt sagen kann, während der Dach rumpelt noch, du können wir da drüben noch umbauen und da noch umbauen.

Ich brauche das eigentlich anders und wir haben festgestellt, der Plan so geht nicht.

Und ein guter Dachdecker sagt dann, ja, man war was jetzt anders, man macht ja da drüben so und so und so und so.

Und der weiß halt, wo seine Grenzen sind, wo man das halt gut umsteuern kann.

Ich muss nicht langsam die Endrunde einleiten.

Ich bin übernächtig von den letzten Zeitungen.

Die Diskussion wird auch langsamer.

Ja, aber du findest natürlich beim Dachdecker halt die Ineffizienz in Kauf her, dass du erst was baust, was du damit wegbaust.

Aber es ist einfach notwendig.

Du kannst nicht vorher wissen, was

ist wichtiger, das unterwegs zu merken.

Deswegen war ich halt, also die Bauherren kann ja immer keiner leiden, der ständig auf der Baustelle ist, aber ich habe die Elektrik bei uns gemacht.

Insofern nimmt man mich dann halt auch ernst, wenn ich da halt eh in der Arbeitshose rumhänge.

Und dann kann ich halt unterwegs die Entscheidung treffen.

Und ja, das war etwas teurer, aber in vielen Fällen gar nicht so viel teurer, als wenn man feststellt, jetzt ist es fertig, jetzt müssen wir uns nochmal aufreißen.

Das ist halt prohibitiv.

Genau, das ist halt genau die Sache.

Wenn du eine Veränderung früher bemerken kannst, dann musst du sie früher reintun.

Das spart Kosten.

Und je früher du sie bemerken kannst, umso früher solltest du versuchen, sie zu bemerken.

Das ist so generell dieses generelle dahinterstehen, oder?

Dass du die Änderungen, die du machen musst, so früh wie möglich bemerkst.

Information, Information, Information.

Ich hätte nochmal so eine Idee, was man vielleicht noch am Schluss machen könnte.

Ich meine, damit das auch irgendwie außer so ganz luftigen Gedanken ein bisschen Content bekommt.

Weil was gibt es denn so für Tools oder so, die man da benutzen kann?

Habt ihr positive Erfahrungen mit irgendwas gemacht?

Vor allem auch noch.

Oder Python, ja genau, auf die letzten drei Monate, wo wir uns da doch alle irgendwie mehr mit Tools beschäftigt haben, weil irgendwie bestimmte Sachen einfach nicht mehr so gehen.

Also ich habe in den letzten drei Monaten sehr viel mit GitLab gearbeitet.

Und das geht so ein bisschen daran, was der Christian vorhin erzählt hat.

Das Ticketboard im GitLab, das ist sehr, sehr lightweight.

Das ist im Wesentlichen, wenn man es so benutzen möchte, eine To-Do-Liste, die man hoch und runter ziehen kann und rechts und links

verschieben kann.

Fast ja, aber auch an einem Kanban-Board hängst du normalerweise nur die Überschriften hin und im GitLab, wenn du es so verwenden möchtest, sind es einfach nur erstmal die Überschriften.

Man kann da natürlich dann auch, sag ich mal, ganze Tickets draus machen, aber so dieses einfache, hier ist was zu tun und hier ist ungefähr die Reihenfolge, in der es wichtig wäre, das reicht schon aus.

Das ist sehr, sehr lightweight.

Das ist sehr wenig Steuerung, aber die Steuerung kommt dann halt von unten, von denen, die es machen.

Da sagen, okay, dieses eine Ticket ist zwar höher eingetragen, aber das andere geht schneller.

Oder das andere erleichtert mir das Leben oder das andere bin ich jetzt gerade in der Stimmung dafür.

Auch das ist was, was in Agile vorkommt, ja, der Unterschied zwischen Push und Pull, wo du eben nicht von oben vorgibst, was getan wird und in welcher Reihenfolge, sondern wo du sagst, hier sind die Dinge, die erledigt werden müssen und von unten die Leute, die es machen, die sagen dann, okay, jetzt mache ich das und dann das und dann das und dann das.

Das hat da sehr gut funktioniert.

Das war sehr angenehm.

Also die GitLab-Issues und GitLab-Boards haben für mich genügend Flexibilität, um einen sehr angenehmen Arbeitsmodus zu erreichen.

Mir geht's ähnlich, ich mag das, wenn Systeme auch so duale Benutzungsmöglichkeiten haben.

Also wir sind momentan bei uns, wir haben jetzt mehrere Fockbugs benutzt.

Das ist ein System, was auch einer der Internet-Urgesteine von Jules Bolski und so.

Und mit dem Werkzeug sind wir sehr happy.

Die haben leider, haben sie das Produkt an ein separates Unternehmen verkauft und seitdem ist vor einem Jahr hätte ich noch irgendwie gesagt, hurra, hurra, hurra, kauft das bitte alle.

Und jetzt muss ich sagen, fuck, wir müssen davon weg, weil die halt einfach echt, das bricht alles zusammen.

Ist das tatsächlich auch bisher verkauft worden?

Nee, das war Trello.

Trello, ja, genau.

Ja, okay.

Aber es ist ja ähnliche Geschichte.

Trello ist auch ein Joel-Tool, genauso wie Stack Overflow halt.

Und die, was die sehr gut gemacht haben, ist tatsächlich dieses ganze den Bedienungsflow, zumal zwischen Ticket, also dass du so unterschiedliche Repräsentationen von Listen, Trees und so einem Kram haben kannst.

Und die haben schon sehr zeitlich ein sehr fluffiges User Interface gehabt, was sich extrem schnell bedient.

Und ihnen war wichtig in der Abgrenzung zu Jira, das war ja lange Zeit eine harte Konkurrenz.

Jira ist ihnen dann davon gelaufen, was die Marktanteile anging, dass sie gesagt haben, wir wissen, wie die Workflows sind.

Wir haben ja eine Meinung, wie gute Workflows ein gutes UI funktioniert.

Und das war dann die Abgrenzung zu Jira im Sinne von, ja, mit Jira kannst du alles machen, es hat halt keine Meinung, es hat halt keinen Arsch in der Hose und es ist halt dann häufig völlig zerkonfiguriert und völlig kaputt.

Das hat uns an dem gefallen.

Plus, die haben auch eine Integration mit E-Mail, wo du ein wirklich hochwertiges Support-Tool gleichzeitig drin hast.

Und du musst dich bei einem Ticket nie entscheiden, ob das jetzt mit Kundenkommunikation oder interner Kommunikation ist.

Du kannst jederzeit dazwischen im Ticket sagen, du bist jetzt ein Mitkunde- oder ohne Kunde-Ticket und ich habe die Historie und ich kann genau sehen, und sie haben einen richtig guten E-Mail-Client dann auch sozusagen so mit eingebettet, dass sich das auch anfühlt wie: Ich schreibe jetzt eine Kunden-E-Mail und der kann das dann irgendwie sehen und gleichzeitig kannst du dann Kanman-Boards ziehen.

Das war eigentlich alles sehr fluffig.

Wir orientieren uns gerade Richtung Odo.

Das ist so ein Open Source, eigentlich Enterprise Resource Management-Ding.

Die haben aber im Prinzip sozusagen alles in Boards gepackt.

Sämtliche Arten von Ressourcen kannst du immer in irgendwie Board sichten oder Listen oder die haben so einen abgefahrenen Excel-Roundtrip-Export.

Kannst du sozusagen irgendeine Query von irgendeiner Ressource als Excel ziehen, im Excel bearbeiten, das Excel wieder hochladen und dann zerpflückt das wieder und macht dann die Änderungslisten draus, die du im UI hättest machen wollen.

Hört sich krass an.

Das ist nicht so schwierig.

Ja, du bist eigentlich, ja, ja.

Also, aber das ist bestimmt nicht so schwierig, das ist meistens der Weg ins Verderben.

Das kann auch nicht so schwer sein.

Ich mache das noch schnell fertig.

Ja, also da gucken wir uns gerade so ein bisschen um.

Aber ja, und ansonsten muss man, finde ich, mit den Boards, wenn man so über Boards nachdenkt, muss man immer daran denken, Canban, das hat man jetzt ja als Methodik noch nicht angerissen.

Aber diese Flow-orientierten Sachen, die gehen im Prinzip davon aus, dass die Einheiten homogene Größen haben.

Wenn du dir dein Arbeitszeug zurechtlegst und über Flow managen möchtest, dann musst du im Prinzip Dinge tun, die vorhersagbare und ähnlich große Items haben, weil du sonst ständig in den Head-of-Line-Blocking kommst.

Dann gibt es plötzlich das eine fette Ding, was du jetzt angefangen hast und fertig machen musst.

Und es sitzt da mittendrin und es geht nicht voran und dann hast du irgendwie dieses Work-in-Progress Limit.

Das heißt, ein anderes darf jetzt auch nicht rein und dann kommen wieder diese starren Regeln zu tragen und dann lässt du die Regeln aber sein, dann explodierst sie wieder auf eine andere Art und plötzlich hast du halt wieder Ticket-Chaos.

Ja, ja, ja, du musstest dir alle zerlegen.

Ja, nee, das Problem ist, Flow-Systeme, wie hier Toyota, ähm Toyota Production System und solche Sachen, die sind halt produktionsorientiert.

Mach mir bitte 20 Prios.

Und das ist was anderes als, oh, erfinde bitte ein neues KI-System, was irgendwie was ist für ein Ticket?

Ja, ja.

Ja, würde das eine Rolle spielen, ob das irgendwie Python-basiert ist oder nicht?

Weil es gibt da so ein Ding, das halt auch so ein bisschen sich, glaube ich, was die Komplexität angeht, so zwischen irgendwie Trello und Jira irgendwie ansiedelt.

Tiger, das ist halt Genre Rest Framework und irgendwie sah ganz nett aus.

Ich habe es mal irgendwie installiert oder so ein bisschen mit rumgespielt, aber hab's dann auch nicht weiterverfolgt, weil, naja, gut, also da, also so beruflich ist auch momentan eher so GitLab und Jira irgendwie sind die Geschichten, die ich verwenden, fünf da.

Ich finde bei den Tools ist es egal,

weil die geschrieben sind, solange die gut funktionieren.

Ich habe mal Tiger versucht zu installieren und hab's nicht hingekriegt und da hatte ich dann keine Lust mehr drauf.

Tiger hatte ich weggelegt, weil die, also wir haben eine relativ lange Historie, wir hatten irgendwie alles.

Wir hatten mal einfach Whiteboards mit so normalen Post-its.

Ihr macht ja auch vier Teams und jedes probiert was aus und dann habt ihr irgendwann mal alles ergänzt.

Nee, nee, nee, aber wir hatten, also 99 hatten wir angefangen mit Baxilla, glaube ich.

Dann haben wir irgendwann den Request-Tracker gehabt, dann haben wir Redmine gehabt und was haben wir noch was hat man noch so gehabt?

Trello immer so ein bisschen, Zamatt haben wir mal angetestet, reicht viel Zeug so.

Und was ich jetzt wiederum, weswegen wir in Richtung Odo gucken, und Odo ist selber auch in Python geschrieben, aber das ist so mehr nachgeordnet, weil die eine gute API haben.

Bei Odo ist dieses Projektmanagement im ERP-Prozess überall mit angedockt.

Die haben sich relativ viel Mühe gegeben, so ein allgemeines, fast schon SAP-artiges System aufzubauen und haben dann aber fachlich kompetent einzelne Module, die gut ineinander übergehen.

Du kannst zum Beispiel, wenn du dann einen Verkaufsprozess hast und dem Kunden ein Projekt verkaufst, kannst du im Verkauf schon sagen, das ist ein Projekt der und der Art, kannst dir da irgendwie dran tackern, was da irgendwie die Kalkulationsstrukturen sind, so typische, was legst du noch an Anhängen dem PDF bei, etc.

Und wenn der Kunde sagt, so das machen wir jetzt, dann kannst du in diesem Auftrag draufklicken, ja, das wird jetzt ein Projekt und kannst gleich für dieses Angebot ein passendes Projekt-Template in hier habe ich ein Bot, das sind die 50 Sachen, die jetzt zu tun sind, rauslassen und die sind alle aneinander geknüpft und du kannst die Stunden, die da reingehen, gleich in den Auftrag buchen.

Und das war so ein, okay, hier geht irgendwie, du kannst alles mit allem verknüppern.

Da hat es mir so ein bisschen die Sprache verschlagen.

Mit Software wieder Sachen erschlagen.

Also ich muss aber sagen, gerade wenn man jetzt Remote arbeitet, ist vielleicht jetzt gerade was anderes, aber wenn man irgendwie jetzt nicht Remote arbeitet, sondern in so einem Office ist, finde ich diese klassische, wir haben jetzt so Whiteboards und hängen da Post-its hin, Sache sehr cool, weil das halt so eine Haptik hat und man muss aufstehen und da hingehen und mal so die Distanz ändern und hat das halt nicht in irgendwelchen verschwurmelten Tickets, sondern sieht das alles irgendwie so vor sich visuell und das hat irgendwie einen riesen Vorteil.

Man braucht mal ganz viele Boards, aber wenn man da was geht, ich finde das sehr charmant.

Und du hast halt keine Nachverfolgbarkeit, das ist halt schwierig.

Ja, vielleicht muss man das so irgendwie dann abmerken.

Das ist gut.

Nein, vielleicht haben wir es angeschaut.

Weil man, der nicht da ist, das nicht sehen kann.

Nein, nein, nein, Nachverfolgbarkeit kommt halt immer drauf an, weil da gibt es halt auch eine interessante Dynamik, weil Transparenz im Unternehmen ist keine absolute Größe.

Weil es meint

ja die Leute, die da mit dran beteiligt sind.

Ja, ja, ja, warte, warte, warte.

Transparenz hat das Problem, zu viel Transparenz killt dir die Innovation, weil keiner traut, irgendwas zu machen, weil es könnte in zehn Jahren noch irgendwer lesen, dass er mal eine blöde Idee hatte.

Zu wenig Transparenz und du hast.

Ja, kurz dich schon einfach machen.

Zu wenig Transparenz bedeutet wiederum, dass halt Korruption reinkriegst.

Da brauchst du Transparenz.

Und ich weiß, dir geht es gerade darum, wenn du gemischte Teams hast, wenn du halt Leute hast, die gerade krank waren oder die gerade irgendwie etc.

So, was ich aber halt, wofür ich so Whiteboard-Prozesse, ja, irgendwas ist immer, wofür ich Whiteboard-Prozesse halt gerne nehme mit dieser Haptik, ist tatsächlich eher so ein workshop-orientiertes Verfahren, wo du sagst, okay, jetzt sind wir hier die vier, fünf Leute gerade mal vor Ort und du willst diese High-Bandwidth, Low-Latency-Kommunikation, die Menschen halt, wenn sie vor Ort sind, halt einfach mal volle Kanne ausnutzen.

Dann machen sich so Sachen mit Whiteboards und wir haben auch so extra hexagonale Post-its, weil die sich gut clustern lassen.

Kein Ziel, was ich mir zeigen könnte.

Ja, ein hexagonales Post-it.

Und die nutzen wir dann und dann werden die abfotografiert.

Und aber im Prinzip wird jeder, der da war, verschriftlicht sich die Erkenntnisse und danach wird das ganze Ding wieder weggefaltet und weggepackt und dann geht es irgendwie in Tickets weiter.

Aber das ist halt so ein temporäres, man muss auch mal Mut haben, auch mal Sachen abzuschneiden und zu vergessen und zu verlieren.

Mein Komponent sagt dann auch immer wieder, die wichtigen Sachen kommen wieder.

Ja, so kann man das nicht.

Es ist erstaunlich.

Wenn man zu viel Mail kriegt, eine gute Strategie einfach nicht mehr drauf reagieren.

Aber nicht.

Die wichtigen Sachen erreichen dann über andere Wege.

Wer schreit, hat noch Reserven.

Ja, das ist doch ein schönes Stichwort zum Thema Projektmanagement.

Wer schreit, der

kann noch.

Schöne Folge.

Ja, ihr habt jetzt da trotzdem vergessen XP und es ist ganz tatsächlich, ich bin ein bisschen böse.

Vielleicht muss der Jochen das gleich noch alleine nachmachen.

Machen wir nächstes Mal.

Ja, genau.

Wir machen einfach Teil 2, die Details.

Wir machen das wie beim Känguru, der Jochen spricht jetzt noch die Fußnoten an.

Das kann jeder in den Shownotes nehmen.

Genau.

Ja, genau.

Also zum Extreme Programming gab es nochmal so einen Podcast irgendwie bei Castro AliExpress, ich glaube, die Nummer 28 war das mit Pavel Mayer und Temp.

Ja, der war der Schwert.

Das war schon ein bisschen älter, 15 Jahre oder so.

Das ist immer noch gut.

Du kannst ja nicht neu erzählen.

Der hat mich damals damals schon Podcast.

Ja, und ich habe das damals schon gehört.

Das Ding hat mich damals dazu gebracht, irgendwie zu überlegen, dass wir haben damals in der Firma, da war Wasserfallgeschichten gemacht und als ich das gehört habe, dachte ich mir so, das muss irgendwie anders werden.

Das kann nicht so bleiben.

Und genau, ja.

Ja, vielen Dank für deine Projektmanagement-Folge, die endlich hinbekommen haben.

Also das Projekt Projektmanagement-Folge haben wir jetzt quasi erfolgreich abgeschlossen.

Wie fühlt ihr euch?

Ich weiß nicht, wie geht man denn das Projekt nach?

Muss man das nochmal aufbearbeiten, um das nächste Projekt Learnings mitzunehmen?

Macht man so ritualisierte Verfahren?

Geben wir uns alle einen High-Five am Ende.

Das Ende eines Projektes.

Anfang des nächsten Projekts.

Du hast vor einer halben Stunde schon gesagt, bis dann zum Ende kommt.

Ja, cool.

Nö, fand ich auch echt interessant.

Ja, dann vielen Dank, dass ihr viele noch offen wieder, Dominik sagt.

Da kann man sicherlich nochmal eine Folge draus machen.

Feedback, weitere Wünsche, hallo at python podcast.de.

Bleibt uns gewogen.

Schalt immer wieder rein.

Vielen Dank, dass ihr dabei wart.

Bis zum nächsten Mal.

Bis zum nächsten Mal.

Tschüss.

Tschüss.

Danke.

Tschüss.

Tschüss.