Agilität und Qualität: Was macht gute Software aus?

00:00:00: Herzlich willkommen zu einer neuen Folge Comfort Talking der Starface Podcast. In dieser Episode reden wir mit Andreas. Er ist Team Lead im Software Development bei Starface.

00:00:09: Er erzählt uns, welche Veränderungen und Herausforderungen mit dem Wechsel vom Entwickler zum Team Lead entstehen, wie er diese löst und was er bisher aus dieser

00:00:16: Entwicklung gelernt hat. Wir sprechen außerdem über die verschiedenen Rollen innerhalb eines Entwicklungsteams und welche Balancen es bei der Arbeit in diesem Team zu beachten

00:00:24: gibt. Andreas gibt uns Einblick in das agile Arbeiten im Entwicklungsprozess. und wie dabei Qualität und Agilität Hand in Hand gehen.

00:00:31: Außerdem reden wir über die Schnelllebigkeit von Technologien im Bereich der Softwareentwicklung und der Nachfrage vom Markt. Außerdem erklärt er uns, wie er das Gleichgewicht zwischen seinen Rollen als Teamlead, Developer und auch Mentor findet.

00:00:43: Und jetzt wünschen wir euch viel Spaß beim Anhören.

00:00:49: Andreas, schön, dass du da bist. Erstmal an die Frage, wie geht's? Wie steht's? Wunderbar, ich freue mich jetzt auf den Podcast und bin ein bisschen aufgeregt, aber ich glaube,

00:01:03: das wird sich gleich legen und freue mich, dass ihr mich eingeladen habt, vor allem auch. Ja, schön, dass du da bist. Aufregung ist auf gar keinen Fall nötig.

00:01:10: Alle Gäste, die wir bisher hatten, haben am Ende gesagt, so schlimm ist es nicht, als wir fertig waren und von daher, keep it easy.

00:01:19: Wir haben dich hier eingeladen, weil du auch einen, ja jetzt nicht wahnsinnig besonderen, aber doch einen interessanten Werdegang auch bei Starface hingelegt hast. Ich fasse es mal grob zusammen, du darfst mich gerne korrigieren.

00:01:33: Du hast also den Weg gemacht quasi vom Software Developer jetzt zum Team Lead innerhalb des Starface Engineering. Und was man natürlich dazu sagen muss ist, du machst das Ganze ja auch größtenteils remote.

00:01:49: Ja, genau. Das ist 100 Prozent remote, würde ich es nennen. Und 2016 habe ich bei der Starface angefangen und 2019 bin ich dann Teamleague geworden.

00:02:01: Und das Ganze halt remote. Und da gibt es diverse Herausforderungen, die man dem begegnen muss. Also remote ist das eine, von der Technik zur Führungskraft ist das andere.

00:02:18: Da sind auch... einige Dinge, die man beachten kann und wo auch so ein paar Fallen warten, wenn man so will. Lass uns doch gerne vorne anfangen quasi. Das heißt, dein Einstieg bei Starface, was

00:02:32: war deine erste Rolle, die du hier angenommen hast? Genau, so eingestiegen bin ich 2016 als Softwareentwickler und Architekt und ich habe die...

00:02:44: Das erste Jahr habe ich quasi bei der ABM Hauptprodukt mit gearbeitet als Softwareentwickler. Das heißt, dort habe ich mit an der PBX gearbeitet.

00:02:53: Das Kernprodukt, was alle unsere Partner täglich nutzen und einsetzen und entsprechend verkaufen. Und ein Jahr später habe ich weitere Projekte betreut.

00:03:07: Das war damals eine Central Management Platform, die in Planung war, und später dann die Neon Platform. Das Tool, was wir heute auch nutzen. Genau, das geht dann hier.

00:03:17: Live in Action. Genau, Live in Action. Das heißt, du hast dann das Neon-Projekt quasi auch als Lead schon betreut? Genau. Hattest du davor schon Erfahrung, so ein Team zu leiten durch so ein Projekt?

00:03:35: Immer mal wieder. Also der Werdegang, ich war eine Zeit lang selbstständig. mit zwei Freunden damals. Dort haben wir natürlich auch selbstständiges

00:03:45: Arbeiten gelernt, Planung gelernt. Dann später hatten wir in Exit. Damals hat man das Ganze noch nicht Exit genannt.

00:03:53: Da war ich bei einer größeren Firma. Das heißt, ein bisschen Erfahrung war schon immer da. Allerdings nicht so explizit als Führungskraft, sondern eher als,

00:04:06: ja, weiß ich nicht. In einem Teamstruktur nimmt man sich gewisse Aufgaben, wenn es gleichberechtigt ist. Und dort hatte ich dann oft auch Organisationsthemen.

00:04:15: Das heißt, du warst eigentlich so ein bisschen der Koordinator innerhalb des Teams? Genau, genau. Also von daher schon Erfahrungen gehabt, aber ich fand es gut, als das Ganze eingeführt worden ist.

00:04:26: Also ich glaube, auch 2019. Die Staffel ist ja gewachsen, wir wachsen fortwährend und wachsen organisch größtenteils. Als ich angefangen habe, waren wir, glaube ich, um die 80 Mitarbeiter.

00:04:38: Heute sind wir ja schon die 350, 160. Das ist ein Doppelteam. Genau. Das Engineering-Team ist natürlich auch in der Zeit gewachsen.

00:04:46: Für unseren damaligen Head of Engineering war das nicht mehr machbar, jeden einzelnen Entwickler zu betreuen. Dementsprechend gab es auch den Zwang, bei ganz so viel Management einzuführen, noch

00:04:58: eine Ebene dazwischen. Und in dem Zuge sind eigentlich in allen Teams dann Teamleads berufen worden. Und was ich auch sehr gut fand, dass dann einfach nicht nur gesagt wurde,

00:05:09: na, du warst Software-Entwickler, jetzt bist du Führungskraft. Viel Erfolg damit. Sondern innerhalb der Starphase legen wir viel Wert dann eben auch auf Schulung.

00:05:19: Was bedeutet es, Führungskraft zu sein? Welche Rechten und Pflichten habe ich? Wie wollen wir das kulturell in der Firma gestalten, das Thema Führung?

00:05:27: Und da, finde ich, sind wir sehr, sehr offen und auch lernbereit. Cool. Wie hat sich da so dein Team entwickelt?

00:05:35: Also ist das auch mitgewachsen oder seid ihr quasi, seitdem du dann Teamlead wurdest, irgendwie stehen geblieben, was die Personenanzahl anging?

00:05:43: Oder hat sich das auch nochmal weiterentwickelt? Es ist, glaube ich, leicht gewachsen. Eine Person nochmal dazu.

00:05:52: Wobei ich jetzt auch noch mehrere Teams habe. Also es entwickelt sich natürlich dann auch immer weiter.

00:05:57: Damals fand ich es sehr interessant, als wir quasi gleichberechtigte Entwickler waren und dann jemand, und zwar in dem Fall ja meine Person, zur Führungskraft wurde, änderte

00:06:10: sich sofort die Beziehung. Also das war schlagartig, war ich erstmal so, hm, du bist jetzt außen vor, du bist jetzt jemand anders. Und das musste sich dann erstmal wieder einspielen.

00:06:21: Also, dass ich halt kein neuer Mensch bin in der Form. Prinzipien meine Werte und Prinzipien weiterverfolge und dass ich nicht schlagartig jetzt ändert,

00:06:31: weil ich dann deklarativ die Führungskraft des Teams bin. Und das brauchte durchaus ein paar Monate, bis sich das dann wieder einrenkte, wenn man

00:06:40: es so formulieren möchte. Und das war sehr spannend, dieser zwischenmenschlichen Beziehung dann zu sehen, wie sich dann schlagartig verändern und im Nachhinein aber dann doch festgestellt ist, wahrscheinlich festgestellt

00:06:52: wurde, Andreas ist Andreas. Also das ist dann schon. schon auch aufregend. Ja, ich denke, es ist eine Umstellung für beide Seiten, also sowohl irgendwie für deine

00:07:00: Teammitglieder, die du hast, aber auch für dich. Ich meine, auch du bist da ja irgendwie dann in eine neue Rolle in dem Konklamorat irgendwie

00:07:08: gekommen. Von daher ist es bestimmt, wie ich sagte, für beide Seiten nicht einfach. Ja, also das ist richtig. Auch für mich war das auch durchaus spannend.

00:07:18: Entwickler sind ja eher introvertiert. Und jetzt war die Aufgabe plötzlich Menschen. Oh mein Gott, Menschen sind da mit Bedürfnissen, mit Charakter.

00:07:29: Und man muss sie halt schon alleine. Also wir wollen ein Ziel verfolgen und auch Produkte bauen, die am Markt angenommen werden. Und dieses Team dann auch zu organisieren.

00:07:41: Ich meine, bei mir in dem Fall war es jetzt beim ersten Team, war es natürlich einfacher, weil ich die Leute schon kannte und wusste, wie sie ticken.

00:07:47: Bei neuen Teams ist es dann durch eine andere Herausforderung zu schauen, wie man diese Charaktere zusammenbringt. dass sie kooperativ dem Ziel zuarbeiten.

00:08:00: Genau, und das ist halt ganz, ganz unterschiedlich. Das ist das Teamthema. Auf der anderen Seite für mich natürlich auch.

00:08:09: Organisation und Führung ist durchaus auch anstrengend. Es ist ein ganz anderer Aufgabenbereich. Und wenn man aus der Technik kommt, dann kann man halt sehr einfach fliehen.

00:08:20: Also ich kann dann einfach sagen, Bevor ich mich jetzt mit diesen Problemen auseinandersetze, ob es nun organisatorisch oder zwischenmenschlich ist, ich schnapp immer wieder den Code Editor und bin mal wieder

00:08:29: vier Stunden im Tunnel. Und das ist immer so ein bisschen die Karotte vor der Nase, wo man natürlich aufpassen muss, dass man klar seine Prioritäten definiert als Führungskraft, weil

00:08:43: es macht ja auch Spaß. Also die Leute, die aus der Technik, aus der Entwicklung kommen. die sind normalerweise mit Leidenschaft dabei und wenn es sich dann verschiebt zu

00:08:52: disziplinarischen, organisatorischen Themen, ja, ab und zu macht es dann auch Spaß wieder zurück, es darf bloß nicht zu viel werden, weil sonst leiden halt andere Dinge.

00:09:01: Und das ist auch so ein Prozess, den glaube ich, man sich jedes Mal wieder bewusst sein muss. Ansonsten passt einfach die Zeit nicht. Also man kann nicht mitentwickeln und gleichzeitig

00:09:17: die Aufgaben der Führungskraft wahrnehmen, weil die durchaus vielfältig sind. Also das ist schon ein Spannungsbogen. Gleichzeitig ist es schon so, dass du als technische Führungskraft irgendwo dieses

00:09:31: Mentoring bieten musst, gerade für die Leute, die neu sind, die als Junior kommen. Kann ich natürlich aus dem Erfahrungsschatz Dinge mitbringen und mitgeben.

00:09:40: Und das funktioniert natürlich auch für eine gewisse Zeit, aber irgendwann sehen Leute auch besser. Da ist natürlich auch noch mal so ein Kontrast, wenn du immer interessiert bist, aber eigentlich

00:09:51: nicht mehr die Zeit hast, tief in die Technik einzusteigen, dann quasi das Vertrauen abzugeben, zu sagen, das ist jetzt wichtig und eigentlich habe ich solche Dinge programmiert, aber jetzt

00:10:01: muss ich es abgeben. Jetzt muss ich halt sagen, okay, ich vertraue denjenigen in meinem Team, nehme nicht diese Aufgabe als erste, wie ich es fast früher gemacht habe, weil es mich auch einfach interessiert

00:10:10: hat, sondern delegiere es und abgeben ist da auch schwer. Gerade wenn du aus der Technik kommst, Spaß daran hast und da auch viel Energie rausziehst aus der Softwareentwicklung.

00:10:25: Und das zu wandeln, dann zu sagen, ich ziehe Energie aus dem Team, aus den Menschen, die mit mir gemeinsam Dinge erreichen, das ist natürlich auch etwas, wo man ein bisschen, ja, wo man sich dran gewöhnen muss.

00:10:38: Ja. Dein Tag hat ja jetzt auch nicht mehr als 24 Stunden bekommen, nur weil du zum Teamlead, sag ich mal, promoted wurdest. Versuchst du trotzdem so ein bisschen, beziehungsweise wie schaffst du es für dich so die Balance zu finden aus der Arbeit, die du, ich sag mal, noch am Code verrichtest sozusagen,

00:10:56: der Arbeit, die dein Team dir macht, beziehungsweise für die du zuständig bist innerhalb des Teams und deinem technischen Interesse, weil ich mein, du sagst es richtig, man muss natürlich gewisse Dinge abgeben, aber trotzdem willst du natürlich nicht irgendwie komplett...

00:11:16: den Ball verlieren, was technischen Fortschritt angeht. Und ich meine, wenn man dieses Interesse einmal hat, wird es ja auch nicht dann verschwinden,

00:11:22: nur weil die Stellenbeschreibung auf einmal eine andere ist. Also wie bringst du diese drei Sachen so in Einklang bisher?

00:11:28: Genau, also ich kenne es eigentlich bei allen, dass im Grunde alle immer auch privat natürlich an diesem Thema Interesse haben. Und in der heutigen Welt sind solche Themen wie Smart Home, IoT, welche Möglichkeiten

00:11:41: habe, dann bastelt auch jeder zu Hause rum. Das ist sicherlich etwas, was man in seiner Freizeit umsetzen kann.

00:11:48: Innerhalb des Firmenkontextes wird es weniger, ganz klar. Was ich mir ab und zu nehme, ist dann zusammen,

00:11:55: ich schreibe zum Beispiel einen Test für einen Bereich. Test Roofing Development, das heißt, wir wollen große Testabdeckung

00:12:04: und wollen damit Sicherheit in dem Programm, dass die stabil laufen, dass die Qualität stimmt. Als Teamlead kann man auch durchaus mal einen Test schreiben, weil das Scope dann sehr klein ist.

00:12:13: Es ist sehr gut berechenbar, wie viel Aufwand das ist. Und ich habe halt trotzdem die Möglichkeit, A, nichts kaputt zu machen.

00:12:20: Ist ja auch gefährlich. Da kommt dann wieder der Spruch, boah, Andreas, warst du wieder im Projekt? Das haben wir aber nicht so gern.

00:12:26: Und bei so einem Test kann ich halt nichts kaputt machen. Trotzdem sehe ich halt, was die Kollegen bauen und was sie sich an neuen Dingen quasi erarbeitet haben.

00:12:37: Und auf der anderen Seite klar. Wenn mal alle im Urlaub sind und es ist ein Buckfix zu tätigen oder sowas, dann versuche ich halt auch reinzuschauen.

00:12:47: Ein weiterer Aspekt sind Code Reviews. Also wir machen in fast allen Teams, denke ich, machen wir Code Reviews. Das heißt, jemand programmiert etwas und dann weiter schaut sich den Code an,

00:12:58: passt ja quasi zu der Idee, der Architektur. hat er die Coding Styles drin, hat er vielleicht nicht neue Dinge erfunden,

00:13:07: die schon woanders verfügbar sind, also hat er Sachen wiederverwendet und stimmt grundsätzlich die Qualität. Das machen wir in so Code Reviews und auch da schaue ich gerne rein

00:13:17: und erfahre auch so, was passiert in der Software und was gibt es für neue Trends. Dann ein weiterer Aspekt natürlich einer Führungskraft bei uns.

00:13:30: Neben dem Produktziel und Entwicklungsziel und den Timelines und so weiter, sind natürlich auch versuchen, Spielräume zu ermöglichen. Und Spielräume bedeutet im Grunde bei uns in der IT, sagt man ja so salopp, ein echtes

00:13:48: Jahr sind vier IT Jahre. Also das ist einfach eine unheimliche Geschwindigkeit. Und in unserem Job ist es halt ein fortwährendes Lernen.

00:13:59: Ich kann halt nie sagen, jetzt habe ich fertig gelernt, jetzt habe ich Level 15, zack, Medaille dran und jetzt brauche ich nie wieder was Neues lernen.

00:14:06: Das funktioniert bei uns nicht. Und deswegen ist es auch wichtig, auch innerhalb der Arbeitszeit Spielräume und Raum zu schaffen, sich neue Dinge anzusehen in der Softwareentwicklung, neue Dinge auszuprobieren, eine kleine Zeit

00:14:24: Sachen, die jetzt in dem Bestandsprodukt nicht umsetzbar sind dort, aber testen kann, Erfahrungen sammeln kann und die dann langsam wieder zurückfließen.

00:14:31: Und das ist halt so viel, das ist privat, kann man das nicht alles stemmen. Und wir im Team bestimmen dann auch zum Teil, okay, was ist denn interessant, was können

00:14:44: wir uns angucken, wo sollen wir ein bisschen Energie investieren und was dabei dann oft auch rauskommt, sind kleine Vorträge. Das hat der Kollege gesagt, ich habe mir das angeschaut.

00:14:55: Der und der Aspekt ist super interessant. Da sehe ich auch eine Verwendung vielleicht an dem Projekt. Ich würde euch gerne das mal zeigen. Sehr cool.

00:15:02: Und das sind so Mechanismen, wo wir versuchen, uns auch am Ball der Zeit zu halten und als Führungskraft.

00:15:12: Und ich glaube, da kann ich für alle Teams reden. Alle Ingenieure brennen für die Produkte, für die,

00:15:18: da ist niemand bei, der sagt, das ist ein 5x8 Job. Und es interessiert mich gar nicht, was ich hier mache.

00:15:23: sondern alle verstehen die Produkte, alle sind involviert. Und dann fällt es halt mal schwer, sich zurückzunehmen und zu sagen,

00:15:28: okay, ich mach jetzt wirklich mal die zwei Stunden was anderes, anstatt an dem Produkt zu arbeiten, eben um mich fortzubilden.

00:15:34: Und jetzt, da sind halt Führungskräfte auf der technischen Ebene gefragt, diese Freiräume dann auch zu schaffen. Also, es ist einfach unfassbar wichtig, da mit dem Ball zu bleiben.

00:15:45: Ja. Das tut dir dem ganzen Team auch langfristig einfach gut, weil ich glaube... Du könntest das natürlich als Teamlead auch so machen.

00:15:53: Du stopfst den Schedule von deinem Team voll mit Arbeit, Arbeit, Arbeit am Projekt. Und dann irgendwann fragt man sich, ja, aber warum kommt jetzt keine Innovation mehr aus dem Engineering?

00:16:04: Das heißt, es ist, glaube ich, wirklich unfassbar wichtig, regelmäßig diese Zeit zu schaffen, den Horizont auch zu erweitern. Und du sagst es ja, die meisten kriegt man dann vielleicht auch schwer davon weg, aber...

00:16:16: Genau, also man... Wie gesagt, ich glaube, alle sind wirklich in den, also es ist einfach so, alle brennen für die Produkte und sind hinterher da gute Sachen abzuliefern und im Fall ist es halt

00:16:28: schwer, einen kurzen Cut zu machen. Trotzdem wollen wir ja innovativ sein und innovativ kann man in den Produkten sein, aber auch in den Werkzeugen, die wir dafür nutzen, um diese Produkte zu bauen.

00:16:40: Und wenn diese Werkzeuge einfach zu alt werden... Ja, dann bedeutet das, dass unsere neuen Features langsam auf den Markt kommen,

00:16:47: dass vielleicht die Einarbeitungszeit immer höher wird, dass die Fehleranfälligkeit steigt, weil wir einfach Dinge nutzen, die nicht mehr am Markt gepflegt werden,

00:16:59: wo es auch kein Wissen mehr gibt, keine Erneuerung mehr gibt. Und so ist es ein stetiger Wandel. Und auch da ist es im Grunde so,

00:17:10: kann ich in die Teams reinschauen oder in die Firma? innovativ und wollen jeden Tag was Neues sehen.

00:17:16: Und was sind denn die Menschen in so einem Engineering Team, die sagen, ich will aber Stabilität, ich will morgen das Feature.

00:17:23: Und ich muss halt schauen, dass ich das entweder im Team habe oder halt in der Firma diese verschiedene Charaktere.

00:17:29: Und da ist dann auch wieder Führungskraft gefragt. Ich darf die nicht direkt aufeinanderprallen lassen.

00:17:35: Wenn der Mensch, der total innovativ ist, stelle ich was Neues. Wir mit dem Menschen, der eher so der Stadtplaner ist.

00:17:42: dann werden die sich nie eins. Die darf ich nicht in einem Projekt stecken, ungesehen. Die prügeln sich. Der eine möchte das alte, stabile und der nächste möchte auf jeden

00:17:55: Fall einen Schritt voraus. Das sind ganz unterschiedliche Bedürfnisse. Da muss man halt auch als Berufskraft schauen, wem gebe ich welche Aufgaben. Und beide Varianten sind extrem wertvoll.

00:18:09: .. das darf man auch nicht vergessen. Also auf der einen Seite... .. Stabilität ist für uns als Kommunikationsunternehmen...

00:18:14: .. extrem wichtig. Auf der anderen Seite... .. dürfen wir uns aber auch nicht abhängen lassen.

00:18:20: Und... .. diese beiden... .. konträren Dinge müssen wir trotzdem in der Firma vereinen. Und... .. das ist halt ganz wichtig. Ganz, ganz wichtig, genau.

00:18:30: War das bei dir... .. war da bei dir ein großer Lernprozess drin? das noch zu koordinieren, diese verschiedenen Typen?

00:18:37: Oder war der Vorteil bei dir, dass du das Team an sich schon eh schon kanntest? Ja, die Frage wird mir auch mal gestellt, was bist du denn, Andreas?

00:18:45: Bist du eher der, der, der Windschauf... Und ich hab da gesagt, da bin ich eine gestörte Person. Ich mag, ich mag das Neue. Also ich renn da gerne hinterher, schau mir das alles an.

00:18:55: Aber ich verstehe auch die, die Notwendigkeit der Stabilität. Weil... Da hängt ja noch mehr dran. Also Softwareentwicklung ist zum Teil Methodik.

00:19:05: Also wie mache ich gewisse Dinge? Da gibt es Methodiken, die sind immer gleich, die kann ich üben. Und wenn ich die üben kann, kann ich die natürlich auch verbessern,

00:19:14: verschnellern, bin zügiger. Das sind halt Prozesse, die ich einüben kann. Das ist halt der Sachbearbeiter, der jeden Tag das Gleiche macht.

00:19:21: Der kann das im Schlaf, nachts wecken. Alles klar. Und diesen Methodik Part gibt es halt in der Softwareentwicklung ganz klar.

00:19:27: Aber es gibt auch die andere Seite, den kreativen Part. Und dieser kreative Part, der sorgt halt für interessante Lösungen, für neue Lösungen,

00:19:36: für unterschiedliche technische Implementierungen, für neue Produkte. Und jetzt muss ich die beiden Welten zusammenbringen.

00:19:43: Und ich denke, da, wo der methodische Anteil sehr hoch ist, da will ich Stabilität. Weil dann kann ich das sehr oft üben und bin auch sehr, sehr schnell in dem Bereich

00:19:51: und habe dann mehr Zeit für die Kreativität. Weil dann schließt sich der Kreis ja auch wieder.

00:19:57: Was ist denn das Risiko bei Softwareentwicklung? Das ist nicht die Methodik. Die Methodik, das haben wir gelernt, das wissen wir, sondern das Risiko besteht ja in diesem kreativen Bereich.

00:20:06: Und das ist dann das Projektmanagement, wo wir dann schauen, wie kann ich das Risiko in dem kreativen Bereich denn kalkulierbar machen?

00:20:16: Gar nicht so leicht. Gar nicht so leicht, genau. Das ist nicht so leicht. Und das reduziert sich dann immer wieder auf die Menschen am Ende.

00:20:26: Das war die Ausgangsfrage. Wie kann ich mit diesen Charakteren umgehen? Wie kann ich mit den Menschen gemeinsam dann Prozesse entwickeln, die dann allen auch gerecht wird?

00:20:38: Ach so, gerecht werden, glaube ich. Also, dass es dann allen gerecht wird in der Form, dass sich jeder mit diesen Prozessen dann auch identifizieren kann und sie leben kann.

00:20:46: Weil ich brauche nicht gegen die Menschen arbeiten. Das hilft in der Regel nicht. Ja. Ist es dann wirklich so, bzw. gehst du mit deinem Team, mit den einzelnen Personen,

00:21:00: aktiv in den Austausch und versuchst das ein bisschen so abzutasten. Das heißt, werden diese diese methodischen und kreativen Teile teilweise auch wirklich personell aufgeteilt?

00:21:09: Oder sagst du, wenn jemand an beidem beteiligt ist, ist er an beidem beteiligt oder sind trotzdem alle an allem beteiligt? Wie ist das bei euch?

00:21:17: Genau, also das geht. Das triggert jetzt ganz viel. Es gibt natürlich... wo fange ich da an? Also vielleicht der erste Satz, jeden Tag Torte essen, dann schmeckt die Torte auch nicht mehr.

00:21:32: Das heißt, wenn jemand eigentlich immer nur nach vorne Neues will, ihm dann eine rettative Aufgaben zu geben, dann schätzt er die neuen anderen Sachen auch wieder. Also

00:21:42: mal zu sagen, es stinkt langweilig, mach es bitte trotzdem, sorg dafür natürlich, dass es weiterhin Spaß macht. Also von daher ist es immer eine Mischung. Es gibt immer langweilige Dinge oder langweilig ist falsch, ist ja nicht der falsche Wort, sondern Dinge,

00:21:57: von dem man genau weiß, wie sie funktionieren. Routine. Routine und das ist gut und das gibt Sicherheit und die macht jeder.

00:22:06: Ein weiterer Aspekt dieser Frage ist natürlich, wir sind jetzt nicht eine riesen Firma mit einem Engineering-Team von 5000 Leuten. Das heißt, wir können uns Wissenssilos eigentlich nicht leisten.

00:22:20: Also wir können nicht es verantworten, dass jemand ganz explizit nur für ein Thema adressiert ist, weil den haben wir vielleicht noch ein zweites Mal, wenn wir Glück haben.

00:22:33: Aber ansonsten haben wir einen Busfaktor von eins und das ist halt unternehmenskritisch. Das heißt, wir versuchen schon, dass alle im Grunde die verschiedenen Belange verstehen.

00:22:47: Jetzt gibt es natürlich immer Vorlieben, also jemand, der im Frontend arbeitet, möchte nicht im Backend arbeiten und umgekehrt. Trotzdem versuche ich meinen Teams schon.

00:22:57: dass sie zumindest wissen, was da passiert, wie es grundlegend funktioniert und dass sie auch mal aushelfen können. Und auf der Basis, würde ich sagen, müssen sie das alle in allen Bereichen auch umsetzen.

00:23:11: Und das leben wir auch so. Das halte ich auch für wichtig. Ja, auf jeden Fall. In Teilen hast du es jetzt schon angerissen für jemanden, der, wenig überraschend wie ich,

00:23:25: Softwareprojekt beteiligt war. Vielleicht nüsst du uns ja nicht im Schnelldurchlauf, aber sagen wir mal so schnell es geht durch ein Projekt mit, das Andreas leitet. Wie sieht das aus so grob von Anfang bis Ende? Ja genau, Projekt vielleicht auch da. Wir sind Produktteams. Es ist auch ein bisschen anders. Produktteams selber sind ja relativ stabil.

00:23:52: Das heißt, klar gibt es mal neue Mitarbeiter oder jemand geht, aber die Produktteams haben halt die Ausprägung, dass sie halt lange zusammenarbeiten, diese Menschen.

00:24:02: Das ist teilweise am Markt anders. Also in anderen Fällen gibt es eher Projektteams, die dann zwischen Produkten sogar wechseln oder es gibt sogar spezialisierte Teams, die gewisse Aufgaben wahrnehmen.

00:24:14: Ich denke aber, dass Produktteams einen großen Vorteil haben. Da gibt es ja diesen Klassiker von Tugman, dass man halt sagt, okay, es gibt so Teamkonstellationen, Forming, Storming und dergleichen.

00:24:30: Und erst wenn mich ein paar Jahre oder 12 Monate mit einem Team zusammengearbeitet, performe ich richtig. Und wenn man das jetzt wieder auf unser Team zurückbildet, was wir da bauen und wie dann der Ablauf ist,

00:24:45: dann ist die erste Voraussetzung halt diese Stabilität, also dass wir quasi im in der Performing-Phase sind. Und wenn wir jetzt ein neues Teilprojekt bekommen, also

00:24:57: wir kriegen jetzt in unserem Produkt eine neue Aufgabe, dann ist zwar die zwischenmenschliche Beziehung nicht anders, aber man muss sich auch wieder mit dieser Aufgabe identifizieren

00:25:05: können. Und dazu gibt es natürlich viele Fragen und dazu gibt es natürlich ganz unterschiedliche Prozesse und ich glaube, jetzt haben wir den Begriff, sage ich jetzt zum ersten Mal, also

00:25:15: Agile. Großes Wort, immer wieder schwierig. Das erste ist auch mein Buzzword, Bingo. Haken dran, genau.

00:25:22: Check. Check, genau. Und da mache ich direkt weiter. Scrum ist dann auch ein Prozess. Nächster Haken.

00:25:31: Jetzt kommen die Wörter, die wir hören wollten. Genau. Und in meinen Teams verfolge ich diesen Ansatz.

00:25:42: Also wir sind... Ich würde schon sagen, dass wir diesen Angel-Gedanken schon umsetzen. Wir arbeiten überwiegend in einem Scrum-Prozess.

00:25:51: Und wer das kennt, da definiert sich schon sehr viel durch. Das heißt, im Scrum haben wir unsere Refinements.

00:26:00: Das heißt, da geht es darum, zu schauen, okay, was ist denn die nächste Aufgabe? Wir schnüren immer so zwei Wochen Pakete, die wir umsetzen wollen.

00:26:10: wenn die Requirements klar sind, wir haben dann so eine Art Definition of Done. Das bedeutet, wann ist denn ein Feature wirklich komplett umgesetzt?

00:26:18: Welche Anforderungen neben dem Code gibt es denn noch, damit es fertig ist? Also ist die Dokumentation fertig geschrieben?

00:26:26: Ist es abgenommen, sind Tests geschrieben? All diese Themen sind in so einer Definition of Done. Und dadurch ist es dann schon sehr, sehr. klar, wie das funktioniert. Die Frage ist halt da, finde ich viel spannender, warum wir das eigentlich alles wollen.

00:26:48: Warum will ich Agile haben und warum möchte ich gerne Scrum basiert haben und warum möchte ich quasi diese Refinements haben, die ja, in denen das ganze Team dann auch mitmacht und nicht nur ich als Teamlead.

00:27:01: Und wenn man das halt... durchgeht, stumpf, dann sehe ich natürlich nur diese einzelnen Bausteine. Und der Arbeitstag ist, montags ist unser Refinement, dann kommt das Produktmanagement,

00:27:14: der Product Owner schlägt seine neuen Features vor. Das sind in der Regel User Stories. Also ich als Benutzer möchte Folgendes tun, weil dann wird es im Team diskutiert.

00:27:27: Dann gibt es eine Aufwandschätzung. Bei uns ist es eigentlich eine Komplexitätsschätzung. Das zahlt dich auch für sehr wichtig. Also wir schätzen keine Zeiten, sondern wir schätzen Komplexität.

00:27:41: Und das ist eigentlich auch, finde ich total naheliegend, wenn ich jetzt irgendeine Aufgabe habe und ich frage dich dann schätze mal die Zeit, dann fängst du ja irgendwie vorne an.

00:27:52: Du willst verreisen und ich sage schätze mal die Zeit bis du ankommst, dann fängst du irgendwie beim Kofferpacken an. Aber Kofferpacken ist ja Methodik.

00:28:01: Das ist nichts Aufregendes. Also ist da kein Risiko drin. Dann überlegst du dir, ich muss mal mit dem Zug zum Flughafen.

00:28:08: Und dann denkst du dir, mit der Bahn, ne? Da hab ich ja ein großes Risiko. Und im Grunde ist es bei der Aufwandschätzung auch so.

00:28:19: Wenn ich nach dem Risiko frage, lenke ich das Gehirn direkt auf genau dahin, wo das größte Risiko ist. Und das größte Risiko und die Komplexität liegen immer nah beieinander.

00:28:33: Und wenn ich das tue, dann komme ich zum Kernpunkt, wo ich sage, wo ich dann natürlich auch wieder die Zeiten ausrechnen kann letztendlich.

00:28:45: Aber ich fokussiere mich erst mal darauf, wo es kompliziert wird und wo ich wo ich unsicher bin und wo ich unsicher bin, da ist halt auch der meiste Zeitverlust

00:28:55: und nicht in der Methodik. Und Wenn man das halt ein paar Monate gemacht hat und dann im Grunde diese Zeitschätzung erarbeitet hat und sagt, okay, ich habe immer in zwei Wochen Rhythmus.

00:29:07: Was passiert als nächstes, wenn ich diese zwei Wochen, diese Arbeitspakete immer einhalte in diesen zwei Wochen, dann habe ich ja meine Arbeitspakete entsprechend klein geschnitten, dass ich das

00:29:16: schaffe. Und egal, was ich dann in die Zukunft mir an Arbeitspaketen vornehme, wenn ich die vorplane, dann kann ich auch wieder eine

00:29:24: Aussage über einen Termin machen. weil dann weiß ich, wie viele ich von diesen Paketen quasi in den nächsten Wochen schaffe, weil ich die immer quasi gleich bewerte in ihrer Komplexität.

00:29:34: Und das ist dann ein sehr, sehr gutes und wichtiges Werkzeug und ist meiner Meinung nach viel aussagekräftiger, als wenn ich immer noch der Zeit am Anfang frage.

00:29:44: Aber dann frage ich gar nicht nach den wichtigen Dingen. Dann wird gar nicht über das Risiko diskutiert, was vielleicht in dieser Aufgabe steckt,

00:29:52: sondern… Der Entwickler sagt dann, wo ist denn mein methodischer Aufwand am höchsten? Da brauche ich ja wieder fünf Stunden. Aber dass dieses kleine Risiko da hinten vielleicht nochmal 15 braucht,

00:30:03: das sieht er in dem Moment dann gar nicht. Ist das dann auch eine der Herausforderungen als Teamlead, dass man dann, vielleicht nicht der Einzige, aber eine der Personen, die dann da die Waage dranhalten muss

00:30:14: und abschätzen muss zwischen Risiko und Aufwand? Genau. immer eine Unterstützungsleistung und nochmal ein Perspektivwechsel vielleicht herbeiführen,

00:30:27: wenn das Team das diskutiert. Grundsätzlich denke ich, ist die Welt heutzutage zu komplex, um zu sagen, das ist der Mastermind, der alles steuert. Das funktioniert heutzutage nicht mehr, sondern in der Softwareentwicklung, das Agile Manifest

00:30:44: 2001, also wovon reden wir, das ist ewig her. Aber durch diese Komplexität ist es einzeln nicht mehr möglich, solche Produkte zu bauen.

00:30:54: Das heißt, es ist eine Teamleistung. Eine Teamleistung bezieht sich dann eben oder kann nur Fruchten, wenn die Leute wissen, was sie dazu tun, also dass sie Ziele klar sind.

00:31:05: Das ist Ziele sind, die motivieren. Ziele sind, die angenommen werden von den Leuten, dass sie verstehen, was sie tun. Also was ist der Kundennutzen, der Business Case und der Business Value da dran.

00:31:18: Und wenn das alles funktioniert, dann bin ich nur noch jemand, der irgendwelche Hindernisse aus dem Weg räumt. Weil ansonsten ist das Team allein, zielgerichtet unterwegs und auch ein Stück weit selbstorganisierend.

00:31:33: Also wichtig ist, da finde ich halt, wenn ich eine Hand Sand hoch nehme und die Luft werfe, dann fallen die selbstorganisiert runter. Das ist ganz klar.

00:31:45: Aber was wir halt wollen ist … dass der Sand ja einem spezifischen Zweck dient. Und das kann zwar schon eine Sanduhr sein,

00:31:54: da ist auch Sand drin, fällt auch runter, aber hat einen ganz spezifischen Zweck. Und da ist Führungskraft wieder ein Thema zu schauen.

00:32:02: Ist das, was das Team sich da überlegt, technisch als auch den Kundennutzen entsprechend, gemeinsam mit dem Produktmanagement zielgerichtet?

00:32:11: Rennen wir in die richtige Richtung. Und das ganze Agile-Thema. soll dafür sorgen, dass halt Abweichungen möglich sind.

00:32:20: Es ist nicht bei einem Zwei-Jahres-Projekt am Tag eins klar, was am Ende rauskommt, sondern es ist klar, dass wir vielleicht eine Abweichung

00:32:29: von 10 bis 15 Grad haben. Aber trotzdem irgendwo zielgerichtet arbeiten. Und das ist halt auch ein Thema, was, glaube ich, sehr wichtig ist

00:32:40: und wo man im Grunde dann als Führungskraft unterstützend tätig sein kann. Ja, auf jeden Fall. Dann habe ich noch eine Anschlussfrage, du hast uns ja jetzt schon mitgenommen, wie es ist, mit dir einen Teil Projekt zu absolvieren.

00:33:00: Was würdest du sagen, macht Projekte mit dir als Teamlead besonders? Bitte? Was würdest du sagen, macht Projekte mit dir als Teamlead besonders?

00:33:09: Projekte mit mir? Ach, besonders, okay. überlege ich mal also Ich glaube, ich bringe eine Menge mit an Erfahrungen, was ich gerne teile.

00:33:24: Also ich bemühe mich schon zu kommunizieren und vielleicht auch ab und zu zu viel, das mag sein, auch die Hintergründe zu erklären, warum wir das tun, warum zum Beispiel jetzt Planning Poker mit der Komplexitätsschätzung,

00:33:39: was ist der eigentliche Gedanke dahinter und das Gleiche gilt auch für die Produkte, an denen ich beteiligt bin. Ich versuche auch immer den Kundennutzen mitzutransportieren,

00:33:52: so wie ich es dann mit dem Produktmanager ausdiskutiere. Da habe ich sehr viele Nachfragen und versuche das auch ins Team zu bekommen.

00:34:00: Gleichzeitig lege ich viel Wert auf die Softwareentwicklung an sich. Was bedeutet gute oder schlechte Software?

00:34:11: Und Softwareentwicklung selber... Da gibt es keine Physik, da gibt es keine Naturgesetze, das entspringt dem Geist und da kann ich alles tun quasi. Und deswegen ist auch kein Softwareprodukt gleich.

00:34:23: Also ich habe die gleiche, das macht exakt das gleiche Outcome, aber intern ist es komplett anders strukturiert. Und da habe ich über die Jahre, glaube ich, ein Mindset entwickelt, was ich sage.

00:34:36: oder wie ich denke, gute Software aussehen soll, damit sie eben unseren Requirements entspricht, nämlich Wartbarkeit, Lead-Time, also von der Idee bis zur Production, wie schnell ist das?

00:34:48: Und das greift alles Hand in Hand. Das geht runter bis zur Zeit der Code, bis hin zum Prozess. Und da versuche ich dann schon auch immer, drauf hinzuarbeiten, im Diskurs.

00:35:02: Also auch da... Im Scrum sind ja die Retrospektiven verankert. Das heißt, man setzt sich regelmäßig zusammen und schaut,

00:35:11: okay, was funktioniert vielleicht nicht gut in unserer Entwicklung? Was funktioniert gut? Was kann man beibehalten?

00:35:18: Und in diesem Diskurs versuchen wir, uns auch weiterzuentwickeln. Und da sehe ich dann auch meine Aufgabe als Mentor

00:35:29: mit dem Team gemeinsam und als Führungskraft eben dort voranzukommen. Und ich denke, dass einfach viele Kollegen davon profitieren, wenn sie mit mir zusammenarbeiten,

00:35:40: weil ich ihnen halt viel mitgeben kann. Und das ist, glaube ich, auch, ja, das ist ja dann meiner, der, wer selbst organisierend ist, das ist ja meine Existenzberechtigung.

00:35:48: Die jüngeren Kollegen mit auf die Reise zu nehmen und sie auszubilden ein Stück weit auch. Sehr cool. Cool. Interessanter Einblick.

00:36:02: Du hast ja vorhin schon kurz angeschnitten, das Thema Werkzeuge in der Softwareentwicklung. Ich könnte dich jetzt ganz langweilig fragen, wie sieht euer Tech Stack aus, aber da du vorhin so schön mir den Gedanken in den Kopf gepflanzt hast,

00:36:15: dass natürlich Softwareentwicklung und auch die Tools dahinter unfassbar schnelllebig sind, frage ich einfach, was war das Letzte, was bei euch rausgeflogen ist aus dem Tech Stack und vielleicht was es ersetzt hat?

00:36:31: Aber da gibt es auch… Welche Modifizierung war so die letzte? Da gibt es das ganz, ganz unterschiedlich.

00:36:40: Also wir haben eine große Erinnerung jetzt. Wir haben im Frontend Vue.js verwendet. Also das ist ein Framework, um Webseiten zu gestalten.

00:36:51: Ganz vereinfacht ausgedrückt. Also auch zum Beispiel Neon ist mit Vue.js gebaut, das was wir jetzt gerade sehen. Und das werden wir durch React ersetzen. Paradigma-Shift, der relativ groß ist, weil man es eigentlich nicht so einfach austauschen kann.

00:37:08: Und da werden wir aber noch ein bisschen dran arbeiten und das ist von so einem Technologiestück, was wir tauschen. Technologie ist ja, also nicht falsch verstehen, dass man das einfach wegwirft,

00:37:22: das ist jetzt eigentlich eher eine Ausnahme. Es geht eher darum, innerhalb der Technologie-Auswahl sich weiter zu entwickeln. Also wenn du jetzt...

00:37:31: dass du dich als Programmiersprache Java siehst. Das war halt sehr, sehr lange konstant und seit den letzten,

00:37:37: boah, stimmt, sechs, sieben Jahren, passiert da sehr viel. Da gibt es dann ganz neue Möglichkeiten, wie ich Code bauen kann.

00:37:45: Es gibt neue Sprachfeatures und die zu adaptieren und die Effizienz da zu nutzen, die da einhergeht, das ist halt auch eine Lernaufgabe,

00:37:56: die ich annehmen muss, um am Ball zu bleiben. Deswegen kann man jetzt Technik nur als Vehikel für unsere Produkte zu sehen und zu sagen,

00:38:07: Technik kann halt stehen bleiben und Softwareentwicklung kann stehen bleiben. So einfach ist es nicht. Es hat nie einen Selbstzweck.

00:38:14: Es wird ja auch oft gesagt, es ist ein Selbstzweck da irgendwie. Das ist es nicht. Sondern es ist immer eine Idee dahinter.

00:38:21: Und in der Regel ist es eine businessdienliche Idee. Klar gibt es Open Source und gibt viel Spaß und alles mögliche wird gebaut, keine Frage.

00:38:32: Aber der eigentliche Treiber ist natürlich die Wirtschaft und alle Ideen, die da aufkommen, haben in der Regel das Ziel, in den Business Value, Shareholder einzuzahlen, schneller zu werden,

00:38:45: Time-to-Market zu reduzieren, stabiler zu werden und und und. Ja. Und trotzdem ist es nie ein kompletter Bruch.

00:38:53: Das ist eigentlich eher selten. Also. Wenn es ein kompletter Bruch wäre, dann würde ich ja auch selten von meiner Erfahrung profitieren können. Ja. Und ich denke, wie mit normaler Sprache auch.

00:39:05: Du sagst es ja, die hat auch keinen Selbstzweck. Ne, genau. Und auch da, eine Jugendwort dieses Jahr, NPC.

00:39:12: Steht zumindest zur Ausnahme. Es stehen noch ein paar mehr zur Ausnahme. Aufloppt und so. Auch das wandelt sich ja ständig.

00:39:23: Und in der Entwicklung ist es genauso. Man muss halt schauen, dass man dabei bleibt. Auf jeden Fall. Ja, da gibt es so viele Aspekte.

00:39:35: Gerade wenn man jetzt JavaScript anschaut, da poppen ja irgendwie ständig neue Supersets auf. Nennt sich das, glaube ich, korrigiere mich gern.

00:39:45: Und unzählige Frameworks mittlerweile. Das ist wahrscheinlich auch schwer da. Also sagen wir mal so, du kannst uns gerne mal zurücknehmen in die Zeit, als du angefangen hast.

00:39:56: als Developer, da war das Feld schmaler wahrscheinlich. Als ich angefangen habe, kam gerade Java auf die Welt.

00:40:05: Ich glaube 96, 98, um den Dreh habe ich mich mit Java beschäftigt. Das war etwas ganz Neues, weil vorher hatten wir in der Industrie C++,

00:40:17: schon als objektorientierte Sprache. Aber Java hat halt... auch da viele Dinge anders gemacht, auch ein bisschen einschränken da vielleicht.

00:40:27: Und das ganz große Thema war die garbage collection. Also im Grunde ist es bei der Clasp vielleicht bei C++ muss ich mein Müll

00:40:38: halt selber wegräumen oder wenn ich jetzt hier wat Knuddel schmeißen in die Ecke, muss ich halt selber dafür sorgen, dass es wegkommt.

00:40:44: Und Java war halt die nicht die erste Spaß hat noch schon andere, aber quasi die, die sich am Mainstream durchgesetzt hat,

00:40:51: die das für mich ja miterledigt hat. Also ich habe der Möbel in die Ecke geschmissen und das Java Zeug hat dafür gesorgt, dass es weggeräumt wurde. Und das ist halt dann der Cognitive Load im Entwicklerhirn. Den rodeziere ich damit.

00:41:06: Ich muss mich nicht mehr damit beschäftigen, wie ich etwas, was ich allokiert habe, wieder loswerde und kann dann eben mich darauf fokussieren. was wegzulassen. Ich kann mich wieder auf die Fachlichkeit fokussieren. Ich habe eine

00:41:22: weitere Baustelle, die ich nicht mehr betrachten muss und kann mich dann eher mit der Problemlösung beschäftigen und nicht mit den technischen, relevanten Dingen, die mich da eigentlich

00:41:32: stören. Deswegen ist Java auch so erfolgreich geworden. Und auch die anderen Sprachen, also C-Sharp beispielsweise, die haben alle eine Garbage Collection. Go hat eine Garbage Collection,

00:41:43: alle haben sie. Eine. Das ist nicht deswegen passiert, weil die CPU dann effizienter gewesen wäre, weil weniger Strom verbrauchen. Das war damit nicht gegeben, sondern die Entwickler-Performance wurde gesteigert.

00:41:59: Ich kann mich mehr darauf fokussieren. Und jetzt ist es zum Beispiel so, dass halt Rust auf den Markt kommt als neue Sprache. Und da habe ich ein anderes Konzept der Derbitch Collection.

00:42:10: Es gibt in dem Sinne keine, sondern es gibt so eine Verantwortungsbeziehung. Das heißt... Die Sprache hilft mir dabei, mein Müll wegzuräumen.

00:42:19: Tut es aber nicht unbedingt. Und das ist dann wieder ökologisch ganz spannend, weil diese Sprache dann wirklich wieder mehr Effizienz auf der CPU verspricht.

00:42:31: Und jetzt sind wir an so einem Scheidepunkt, finde ich. Diese Sprache ist entweder nur für systemnahe Dinge geeignet oder wird vielleicht

00:42:41: Schare ablösen, wenn die Komfortzone steigt. Und der Druck, der entsteht, kann natürlich sein.

00:42:48: Und das ist dann auch wieder ganz einfach. Ich habe eine Java-Applikation und brauche dafür 500 PCs in der Cloud. Oder ich bau das in Rust und habe nur 250.

00:42:57: Dann wird daraus was umwelttechnisches, aber es wird auch eine Business Value. Also ein Business Thema wird daraus auch. Ich verbrauche weniger Strom.

00:43:04: Und so sind es immer wieder Strömungen, die in der Softwareentwicklung entstehen. Ja, so oder so ist gut, weil Konkurrenz. Ja, klar. Aber es ist natürlich auch eine enorme Einarbeit, da ständig am Ball zu bleiben,

00:43:23: zu weinen, aber natürlich auch Bestandsprodukte. Also unsere Starface PBX, ich glaube, die ist seit 18 oder 17 Jahren in Entwicklung, die wurde nie neu geschrieben, sondern es ist eine fortwährende

00:43:42: Es sind halt hunderte von Edge-Cases da drin, die ich jetzt auch nicht einfach auf der grünen Wiese mal eben neu bauen kann, sondern das ist einfach unfassbar viel Wissen in dieser Zeit eingeflossen. Und dieses Wissen hat ja nichts mit Technik zu tun.

00:43:57: Also bei uns schon mehr, weil wir technisches Produkt haben, aber in der klassischen Entwicklung ist dieses Wissen ja eher fachliches Wissen. Und deswegen ist es natürlich schwer, solche Systeme dann abzulösen, sondern ich versuche eher, Architektur so zu gestalten, dass ich sie verändern kann.

00:44:12: Und das ist halt auch eine immense Aufgabe bei komplexen Produkten und nicht so einfach. Ja, ich glaube auch, das ist die hohe Kunst dabei und eben trotzdem einfach fortwährend

00:44:26: Qualität zu gewährleisten. Genau, und das schließt sich eben auch nicht aus. Also agil zu arbeiten, mit Scrum zu arbeiten und trotzdem Qualität anzubieten, das schließt

00:44:38: sich... Definitiv nicht aus. Wenn jetzt jemand sagt, ja, aber ihr macht ja einen Sprint. Ihr rennt ja den ganzen Tag. Wie wollt ihr denn da auf Qualität achten?

00:44:48: Ihr bekommt ja gar keine Luft. Dann ist das eben genau nicht richtig bedacht, sondern ich denke, dass agiles Arbeiten geht mit der Unberechenbarkeit um,

00:45:02: die einfach existiert, sei es, dass der Markt... morgen eine kleine Änderung will, ein bisschen anders ausgerichtet werden will, sei es, dass

00:45:10: es irgendwelche gesellschaftlichen großen Themen gibt, also was ich Corona kriege oder was auch immer, die ja dann auch wieder Einfluss auf Software haben können. Und wie ich mit

00:45:20: dieser veränderbaren Umwelt dann umgehe, dafür ist das Agile-Thema gut geeignet, weil es halt eben diese Flexibilität im Prozess hat und geschaffen wird.

00:45:33: wird von der Softwareentwicklung ganz unten. Also ich baue auch Anwendungen heutzutage anders, als ich das vor 20 Jahren gemacht habe, weil ich halt sagen muss, dass diese Anwendungen eben auf die

00:45:45: Änderungen am Markt reagieren müssen. Und deswegen entwickle ich solche Dinge etwas offener und austauschbarer. Und das ist halt eine Historie. Also ich...

00:45:59: Es gibt ganz viele großartige Ideen, also das Agile Manifest von 2001 war eine. Und dann geht das wirklich so runter. Da gab es dann das Domain Driven Design, das hat versucht, diese Fachlichkeit besser einzupacken

00:46:12: und mit Vokabeln zu versehen. Da gibt es dann so Bounded Contexte, Domain Events. Also ich habe eine neue Begrifflichkeit, um die Fachlichkeit eigentlich den Technikern

00:46:22: oder den Softwareentwicklern zur Verfügung zu stellen. So geht es über die Jahrzehnte, also über die Jahre dann weiter.

00:46:30: Und dann gab es das Reactive Manifesto, wo man gesagt wird, okay, wir haben jetzt Cloud-Applikation. Was sind denn da für Requirements, die wichtig sind?

00:46:39: Und dann geht es plötzlich um Elastizität, dass ich halt Anwendungen habe, die mit großer und kleiner Last gleichwertig umgehen können

00:46:46: und die Antwort Zeiten von solchen Systemen stabil bleiben. Und so entwickelt sich das natürlich immer weiter und zahlt halt.

00:46:55: in diese veränderte Welt ein, wo Börsenkurse morgen das Zehnfache wert sind, am nächsten Tag wäre die Hälfte und es schwankt alles.

00:47:03: Und niemand kann eigentlich mehr die Zukunft voraussagen. Und genauso, dann mache ich auch unseren Produktmanagern keinen Vorwurf.

00:47:11: Genauso können die nicht mehr sagen, wie unsere PBX in fünf Jahren aussieht. Das ist einfach unfassbar schwer. Und deswegen das annehmen.

00:47:22: Wir können es halt nicht mehr. Es kann niemand mehr für viele. viele Produkte und deswegen lieber die Prozesse ändern und sich eingestehen,

00:47:28: okay, es muss änderbar sein, die Zukunft ist nicht mehr vorhersagbar. Wir lassen uns unseren Arbeitsablauf, die Prozesse, die Anwendung, die Software so

00:47:37: gestalten, dass wir auf diese Änderungen reagieren können und das möglichst schnell. Und das fängt halt bei der Technik, bei der Prozess und endet bei

00:47:49: Menschen, weil auch die müssen wir mitnehmen. das Erfolgsrezept Ideen haben, aber im Hintergrund einfach die Prozesse, wie du sagst, einfach

00:47:59: flexibel halten, weil ich meine, wer hätte vor fünf Jahren gedacht, dass die Welt in fünf Jahren so ist, wie sie jetzt ist? Ja, genau.

00:48:07: Und das ganz größte, nächstgrößte Thema ist ja eben dann KI, neuronale Netze, die, wo ja auch noch niemand weiß, wie wird sich das auf uns auswirken.

00:48:17: Und auch Softwareentwickler sind, der eine sagt, in drei Jahren programmiert niemand das macht die Kaine. Wir haben es geschrieben, wir haben es entwickelt, wir werden es selber merken.

00:48:32: Also auch da muss man halt schauen, wie man jetzt zum Beispiel solche Systeme integrieren kann. Es ändert sich ständig was und wir müssen da flexibel bleiben.

00:48:47: Und bitte schon, das ist ein Kontext der gesamten Organisationsstruktur, die man braucht. Zum Thema KI müssen wir wahrscheinlich noch mal eine neue Podcast-Folge starten.

00:48:58: Auf jeden Fall. Das macht auch viel Spaß. Aber man macht es bunt gemischt. Vielleicht zwei, drei Leute aus ganz unterschiedlichen Stellen. Das Thema KI ist so vielfältig. Ja, da kannst du wahrscheinlich fünf Folgen dazu machen und hast noch nicht alles erzählt.

00:49:11: Ja, ich glaube. Genau. Ich möchte dich abschließend noch was fragen. Und zwar hast du ja auch gesagt, dass du natürlich in deiner Rolle auch Mentor bist. Gerade auch für... .. jungere Teammitglieder, die nachkommen,...

00:49:27: .. hast du für Leute einen Tipp oder ein paar Tipp... .. oder einfach nur einen generellen Hinweis,...

00:49:32: .. die vielleicht diesen Schritt auch machen wollen... .. oder vor der Entscheidung stehen, diesen Schritt zu machen,...

00:49:37: .. den du gemacht hast,... .. zum Mentor zu werden quasi. Genau, also Mentor sein... .. und dann geben wir davon aus,...

00:49:47: .. dass derjenige auch ein paar Jahre in der Softwareentwicklung war. Zum einen glaube ich... Mentor sein ist immer ein geben und nehmen.

00:49:55: Also ich lerne auch jeden Tag was dazu, weil die Details kenne ich natürlich auch nicht. Und dann bin ich ehrlich, erkläre es. Ich verstehe es nicht, weil dann bin ich wieder auf Augenhöhe.

00:50:04: Wenn ich so tue, als wüsste ich alles. Das bringt natürlich auch nichts. Also auf Augenhöhe bleiben beim Mentoring.

00:50:11: Was die Führungskraft Thematik angeht. Es ist halt auch. Man sollte sich bewusst sein. was das bedeutet, also das Disziplinarische, auch mal unangenehm mit Gespräche führen,

00:50:22: das Organisatorische, die Veränderung der Aufgabe und man sollte sich da committen und nicht, wie ich schon vorhin mal erzählt habe, zu oft fliehen und wieder an eine Tastatur

00:50:36: Programme schreiben, als ein einfacher Ausweg ist. Also man sollte sich diesen Aufgaben bewusst sein und man sollte natürlich auch irgendwo

00:50:42: Menschen mögen. Das wäre auch ein großer Vorteil. Noch besteht das Team nicht nur aus KI. Genau. So schwer geht es da nicht.

00:50:55: Vielleicht haben die dann auch gewisse Charakter eingeschafft. Wer weiß wie gut die Modelle noch werden. Genau, simuliere mir den Pedanten.

00:51:09: Oh mein Gott. Andreas von unserer Seite dann schon mal ein ganz... Ganz herzliches Dankeschön. Ja, auf jeden Fall.

00:51:17: Hast du dabei was? Gerne. Wenn du noch ein Schlusswort hast, gerne. Ansonsten? Also ich würde einfach nur sagen, ich mag es bei der Starface, weil wir so viele unterschiedliche

00:51:30: Menschen haben, die alle ihren Platz kriegen und wir immer wieder was Neues erleben können in ganz unterschiedlichen Varianten. Also es wird einfach nie langweilig.

00:51:43: Und gerade aus der technischen Perspektive finde ich, ist das Domain-Modell einfach, wenn ein Telefon klingelt oder nicht. Aber wir haben halt fantastische Technologie-Stacks in allen Bereichen.

00:51:57: Und das finde ich einfach total reizend, also reizvoll nach wie vor bei der Staff ist, dass wir halt so ein bunter Haufen sind der sämtlichen Tech.

00:52:08: den es auf der Welt gibt. Ich habe immer eine pure Freude dran. Das ist dann der innovative Andreas, der sehr stabile, will natürlich wenig ändern. Also von daher nutze ich die Gelegenheit und freue

00:52:24: mich auf Bewerbungen. Das kam jetzt nicht von der HR. Aber die freuen sich bestimmt auch, das jetzt zu hören. Genau, bestimmt. Sehr schön. Schöne abschließende Worte.

00:52:38: In diesem Sinne nochmal Danke an dich. Danke fürs Zuhören bzw. Zuschauen. Genau. Die nächste Folge Comfort Talking gibt es dann im September wieder für euch zu hören.

00:52:51: Und bis dahin sagen wir jetzt einfach mal Tschüss aus Karlsruhe und sagen bis zum nächsten Mal. Genau. Ciao.