Samman Coaching bei der Atruvia AG

Holger: Willkommen bei einer weiteren Folge zu „Unsere Kunden im Interview“ von it-agile. Heute geht es um ein Thema, bei dem ich auch persönlich involviert bin. Technisches Coaching nach der Samman Methode bei der Atruvia AG. Ich spreche heute mit Peter Fichtner.

Peter: Hi.

Holger: Und Ralf Straßner.

Ralf: Hallo.

Holger: Von der Atruvia und mit meinen Kollegen Tim Müller.

Tim: Hallo.

Holger: Herzlich willkommen. Alle drei haben bei der Atruvia viele Teams nach dieser Methode gecoacht. Wir reden heute darüber, was dieses Samman Coaching eigentlich ist und welche Erfahrungen Peter, Ralf und Tim dabei gesammelt haben. Ich selbst gehöre übrigens zum Coaching Team, halte mich heute jedoch ein wenig zurück. Ich hoffe, das gelingt mir und stelle nur als Moderator die Fragen in die Runde. Fangen wir vielleicht doch einfach mal an. Eine kurze Vorstellung von Ralf von der Atruvia. Was ist eigentlich dein Werdegang? Wie bist du zur Atruvia gekommen und was machst du da so?

Ralf: Ich habe tatsächlich direkt zum Ende des Studiums 2011 meine Master-Thesis hier geschrieben und habe danach als Entwickler hier auch angefangen, auch direkt einen Java-Kurs geleitet für Auszubildende. Und ich glaube, so etwa zwei Jahre später 2013 ging es dann auch los mit ASE, zusammen mit Peter und drei anderen Kollegen. Das habe ich dann viele Jahre so nebenher, sage ich mal, gemacht, neben der Entwicklertätigkeit zu etwa 20 Prozent. Bis sich dann vor knapp vier Jahren die Chance ergeben hat, das Ganze als interner Coach in Vollzeit zu machen, wo ich dann wirklich auch gern in diese Rolle gewechselt bin und das bis heute auch weiterhin gern tue.

Holger: Ja, danke. Wie war es denn bei dir, Peter?

Peter: Das Schöne ist, wenn Ralf anfängt, kann ich immer sagen, so ähnlich wie bei Ralf, nur mit etwas anderen Jahreszahlen. Ich habe meine Ausbildung zum Datenverarbeitungskaufmann bei der damaligen Fiducia, heutigen Atruvia, gemacht. Bin 1998 in die Anwendungsentwicklung eingestiegen mit einem Java-Background, also seit 1998 Java Entwickler. Das habe ich auch ungefähr zehn Jahre gemacht. Bin dann in die Architektur gewechselt, war dort unter anderem dann in der Architektenrolle in der Atruvia unterwegs. Und wie Ralf sagte, gemeinsam angefangen, das Thema Agile Software Engineering in der damaligen Fiducia aufzubauen als Nebentätigkeit. Und jetzt eben seit knapp drei Jahren in Vollzeit als Technical Agile Coach - ASE Coach - unterwegs und eben jetzt stark mit Samman Coaching.

Holger: ASE habt ihr ja schon gesagt, ist Agile Software Engineering. Was ist sozusagen die Mission oder das Vorhaben von ASE bei der Atruvia?

Peter: Es geht halt darum, in einem agilen Kontext Anwendungen zu entwickeln. Und da sind Dinge notwendig, die auch in einem nicht agilen Kontext sicherlich sinnvoll sein können. Sowas wie starker Fokus auf automatisierte Tests, ständiges Refactoring, technische Exzellenz.

Wo wir mit ASE angefangen haben, haben wir auch überlegt, ob das „Agile“, ob wir das nicht rausstreichen wollen, weil es generell eigentlich um die Befähigung und Unterstützung von Entwicklungsteams oder Entwickelnden geht. Aber durch die Einführung von agilen Anwendungs- und Entwicklungsvorgehen in der damaligen Fiducia wurde das halt relevant. Und ja, das ist die Mission von ASE.

Vielleicht auch, heute wird man sagen, so Richtung DevOps, dass es um kontinuierliche Lieferfähigkeit geht, technische Schulden nicht zu groß werden zu lassen oder darauf zu achten, nicht zu viele technische Schulden zu haben. Seine Anwendung eben immer „up to date“ zu halten, auch schnell auf Dinge reagieren zu können, beispielsweise Security-Dinge. Also das, was man heutzutage eigentlich unter guter moderner Softwareentwicklung versteht.

Holger: Da fällt mir gerade noch ein, wir haben gar nicht so genau gesagt, was die Atruvia macht oder die Fiducia, die ist ja sozusagen der Vorgänger. Es geht ja schon um Software im Bankenumfeld. Kann das noch mal einer beschreiben? Vielleicht von euch?

Peter: Also früher hätten wir gesagt, wir sind das Rechenzentrum der Genossenschaftsbanken. Das heißt, wir übernehmen die Anwendungsentwicklung und den IT-Betrieb, angefangen vom Mainframe in Hochleistungsrechenzentren über verteilte Systeme, bis hin zu den Bankenarbeitsplätzen, also dort, wo die Bankberater mitarbeiten, Kontoauszugsdrucker, Geldausgabeautomaten, aber auch das Online-Banking. Vielleicht kennt der ein oder die andere uns beispielsweise vom Zertifikat im Browser, wenn ihr Online-Banking bei eurer Volks- oder Genossenschaftsbank macht.

Wir stellen auch die Apps im Play Store und im App Store zur Verfügung. Vielleicht kennt ihr uns daher vom Namen her. Heute verstehen wir uns als Digitalisierungs-Partner. Das heißt, wir versuchen gemeinsam mit den Banken, die Digitalisierung voranzutreiben, um so manuelle Aufwände in oder bei und rund um die Banken zu reduzieren. Weil ich jetzt auch die Atruvia schon mehrfach erwähnt habe: Die Atruvia setzt sich aus der ehemaligen Fiducia und der ehemaligen GRD zusammen, so dass wir mittlerweile jetzt für das gesamte Bundesgebiet tätig sind.

Holger: Und viel früher war das ja sozusagen in einzelne Unternehmen aufgeteilt, in verschiedenen Ländern, die dann immer mehr und mehr fusionierten an der Stelle und dann zu einem großen Konzern wurden. Okay, Tim, du bist ja mein Kollege von it-agile. Wie bist du denn zu der, ich sag mal jetzt Truppe, gestoßen?

Tim: Ursprünglich erstmal als Agile Coach für die Gruppe der Coaches - die gibt es ja immer noch bei der Atruvia. Und dann beim Vorstellen kam immer so ein bisschen raus, dass ich auch mit dem technischen Hintergrund komme und auch gerne auf die Software-Entwicklungstechniken und auch bei den Teams da gerne drauf schaue. Und dann gab es, glaube ich, diesen Moment, wo eben mehr Teams nachgefragt haben und wo es auch den Plan gab, die Modularisierungs-Schulung weiter auszubauen, die damals noch nicht, glaube ich, noch nicht den vollen Umfang hatte. Und dann bin ich eben Vollzeit zu den damals, ich glaube, zwei, drei, also eben zu den ASE-Coaches dazu gestoßen.

Holger: Okay, genau, technisches Coaching, Teams besser machen, auch bei Tests besser werden. Es gibt ja dieses Samman-Coaching und wenn ich mich recht erinnere, seid ihr bei der Atruvia drauf gestoßen. Ich weiß gar nicht, wer das zuerst entdeckt hat, war es Ralf oder Peter?

Peter: Das Schöne ist: weder noch. Ein weiterer Kollege, der uns darauf aufmerksam gemacht hat, auf einen Blogpost von Emily Bache, wo sie bei Info-Q Samman Coaching angeteasert hat. Beziehungsweise der Artikel geht eigentlich tatsächlich drum, wie man TDD in eine Organisation trägt. Und ja, den haben wir uns durchgelesen und das war unser erster Kontakt zu Samman-Coaching.

Holger: Und dann habt ihr ja sozusagen euch das mal angeschaut und gesehen, was das ist. Hattet ihr da schon was im Kopf, Ralf? Du machst gerade das Mikro an, vielleicht hast du einen Impuls?

Ralf: Also was ich sagen wollte, wir haben dann einfach uns das Buch zum Coaching, zum Samman-Coaching noch zugelegt, um da einfach mal tiefer einzusteigen, weil wir eigentlich gleich gemerkt haben, das ist wirklich interessant für uns. So mit den Erfahrungen, die wir gesammelt hatten, hat sich das halt sehr vielversprechend angehört. Und ja, zusammen mit den Inhalten, die man dann auch auf der Website im freien Zugriff hat, haben wir da einfach sehr schnell einen guten Überblick gehabt und haben gesagt, das wollen wir auf jeden Fall mal ausprobieren.

Holger: sammancoaching.org ist sozusagen die Website, wo auch viele Informationen dazu stehen. Samman, was heißt das eigentlich? Es heißt „zusammen“. Und das werden wir uns gleich auch noch mal ein bisschen anschauen. Hattet ihr da schon, also ihr habt das damals gesehen oder einen Hinweis bekommen, habt ihr da schon gedacht nach dem Motto, oh könnte das vielleicht helfen, irgendwas zu lösen, was uns immer so ein bisschen schwer fällt oder wo wir vielleicht mal besser werden wollten?

Peter: Ja, also was wir, wo wir vorher unterwegs waren, häufig als Feedback bekommen haben, da haben wir relativ viel Dojos veranstaltet. Und eines der Feedbacks oder die Feedbacks, die wir bekommen haben, waren relativ häufig, dass die Leute viel Spaß in den Veranstaltungen haben, dass die Leute viel mitnehmen, die Dinge gerne in ihrem Projektalltag einsetzen möchten, auch versucht haben, ausprobiert haben oder es tatsächlich im Projekt anwenden wollen. Und dann eben mit dem Feedback zu uns kamen, ja, ich würde das und das, was wir im Dojo gemacht haben, das wäre absolut sinnvoll im Projekt auch einzusetzen und zu verwenden.

Aber aus irgendwelchen Gründen haben wir es nicht hingekriegt. Wir sind gescheitert. Und das war so für uns der Punkt, wo wir gesagt haben, also es ist auf der einen Seite natürlich schön, dass die Leute Spaß in den Veranstaltungen haben. Das ist natürlich auch wichtig, aber wir wollen es natürlich auch nicht als reine Spaßveranstaltung gestalten. Es steckt ja was dahinter, eine Idee, was wir den Leuten mitgeben wollen, weil es entsprechende Vorteile mit sich bringt.

Und deswegen haben wir gesagt, naja, bringt ja nichts, wenn die Leute nur „Spaß“ haben, aber halt der Einsatz im Projekt dann scheitert. Und deswegen war das für uns der Punkt, wo wir auch damals, wo wir Vollzeit-Coachs geworden sind, gesagt haben, wir müssen den Punkt halt stärken, dass wir die Leute im Projektgeschäft unterstützen, dass sie die Dinge, die wir als sinnvoll erachten, auch tatsächlich anwenden können und am Ende nicht daran scheitern.

Und genau das war auch das, was Emily in ihrem Blogpost dort beschrieben hat. Der Blogpost bezieht sich relativ stark auf TDD, aber sie beschreibt, dass das, wo sie gesehen hat, wo TDD funktioniert, ist, wenn du im Pair oder im Ensemble gemeinsam mit jemandem TDD machst, der dort eben entsprechende Erfahrungen mit sich bringt. Das, so steht es im Blogpost drin, ist mehr oder weniger auch die einzige Variante, wie du TDD in ein Team kriegst: gemeinsam mit dem Team an ihrem Produkt, an ihrem Projekt Code zu arbeiten. Und eben nicht auf irgendwelchen synthetischen Beispielen, wo relativ häufig keine Stolpersteine da sind oder total runtergestrippt, total simplifiziert sind. Dass du halt gemeinsam mit dem Team dort arbeitest, wo es dann eben nicht mehr so leicht ist, wie halt in irgendeiner Übungs-Kata.

Ralf: Also Testen ist schon ein Fokus bei ASE. Aber generell geht es ja um Vorgehen, Entwicklungspraktiken, Methodik. Und da ist das Üben eben was ganz, ganz wichtiges. Es geht viel um diese kleine Schritte - kleine Schritte zu finden, nicht nur beim Testen, auch beim Refactoring, beim Design. Und da sind eben Übungsaufgaben gut, um reinzukommen in das Ganze. Aber ja, sie bringen halt irgendwie nicht die ganzen Aspekte mit, die man dann später braucht.

Und wie Peter schon gesagt hat, dann kommt man eben an diese Hürde und ja, ist da vielleicht irgendwie allein gelassen. Und es ist dann eben auch genau der Punkt, wo man eigentlich das Entscheidende lernt, wenn man diese Hürde überwindet, um wirklich nachhaltig diese Praktiken einsetzen zu können. Wir haben auch schon in der Vergangenheit dann immer gesagt: wir müssen unsere unsere Schulung zum Beispiel mit Coaching ergänzen.

Aber es war immer so eine Ergänzung, das machen wir dann danach noch. Und da kam eben oft auch die Problematik, dass dann irgendwann einfach wieder Zeitdruck, Lieferdruck irgendwie in den Teams herrscht und das Coaching dann doch wieder zu kurz kommt. Ich glaube, so der entscheidende oder ein entscheidender Punkt beim Samman Coaching ist: es ist einfach ein unteilbares Gesamtpaket.

Ja, wir gehen in ein Coaching und da ist Theorie mit drin. Da sind auch kleine Übungen mit drin. Aber die sind Mittel zum Zweck, um eigentlich in dieses gemeinsame Arbeiten zu kommen, um dann eben den Teams genau bei dieser Hürde zu helfen, dass sie eben das Ganze auch wirklich anwenden können.

Holger: Also in ‚Real Life‘ auch mal nutzen außerhalb des Schulungsbereichs mit den Beispielen, die vielleicht zu günstig sind. Hängt natürlich auch vom Schulungsbeispiel ab. Aber das muss man sehen. Dann würde ich gerne noch mal fragen: Wir haben jetzt auch schon ein bisschen über Samman Coaching gehört. Vielleicht Tim, kannst du das nochmal erläutern? Was steckt da sozusagen von den Abläufen eigentlich dahinter? Es gibt Begriffe wie Learning Hour, Inspirational Demo, das greife ich mal jetzt vor. Kannst du vielleicht nochmal erläutern, was tut man da eigentlich so vom Ablauf genau?

Tim: Ja, also das Samman Coaching setzt sich eigentlich vor allem aus zwei Komponenten zusammen. Einmal dieser sogenannte Learning Hour, also eine Stunde eine neue Praktik zu vermitteln, zu erlernen für das Team, wo wir eben tatsächlich mit einem synthetischen kleinen Beispiel üben, mit einer Kata. Die kann sein zu bestimmten Refactoring-Techniken oder auch so eine Einführung in TDD.

Und dann nachgelagert - in unserem Fall haben wir es ja häufig am Nachmittag gemacht - das Ensemble Programming. Ensemble, also erstmal ein anderer Name für das, was viele unter Mob Programming oder vielleicht Whole Team Programming kennen. Also das ganze Team arbeitet gemeinsam an einer IDE, an einem Computer quasi. So im Remote Setting dann eben nicht ein Computer, aber zumindest an einem Stück Software. Und dabei haben wir immer geschaut, so im besten Falle, das Erlernte aus der Learning Hour mitzunehmen ins Ensemble. Und dort halt dann am eigenen Projekt-Code des Teams direkt zu verproben und zu versuchen, auch das dann direkt umzusetzen.

Zu Beginn haben wir dann noch zwei Termine mit dem Team. Ein Kick-Off und dann nochmal einen nachgelagerten Termin. Im Kick-Off schauen wir auf das, was das Team ausbremst. Also, was sind, naja, wie, was bremst euch im, in dem Entwicklungsvorgehen aus? Wo seht ihr eigentlich Probleme? So bewusst noch nicht auf Lösungen schauen. Und in dem zweiten Termin haben wir denn meist eigentlich immer die Lösung oder die Vorschläge fürs Coaching vorgestellt.Und auch so ein bisschen den Kontrakt mit dem Team zu treffen, so das sind die Themen, die wir bearbeiten würden im Coaching. Seht ihr das auch? Seid ihr bereit, das mitzugehen? Und dann eben in das Coaching zu starten. Genau.

Weil du eben noch die Inspiration Demo benannt hast. Die Inspiration Demo, also der Termin, wo wir immer noch versucht haben, so einen Ausblick zu geben. Was gäbe es noch? Was ließe sich noch in eurem Projekt-Code machen? Oder welche Praktiken gäbe es noch, die vielleicht interessant für euch wären? Also ein bisschen diese Inspiration zum nächsten Mal vielleicht auch oder jetzt so nach dem Coaching, wo mögt ihr drauf schauen. Genau, und wir haben es ja auch immer noch mit einer Retrospektive verbunden. Also zu sagen, okay, wie lief es denn jetzt, das Coaching, was nehmen wir daraus mit? Und hoffentlich für ein nächstes Mal.

Holger: Und ich weiß nicht, ob wir das schon gesagt hatten. Das sind dann ja zehn Termine, die dann sozusagen durchgeführt werden. Das ist ja, wenn ich mich recht erinnere, auch ein Vorschlag von Emily, das so zu machen. Ja, und ich weiß gar nicht, hatten wir schon mal kürzere oder längere? Ich glaube nicht.

Peter: Ja einmal, tatsächlich haben wir uns breitschlagen lassen. Ich glaube, fünf oder sechs Einheiten und haben dann alle zusammen inklusive dem Team festgestellt, dass das keine sonderlich gute Idee war. Also die zehn Einheiten machen durchaus Sinn.

Passt ganz gut, dass man bestimmte Dinge oder das, was man sich auch vornimmt, zu einem vernünftigen Abschluss bringt und nicht irgendwie die Dinge so halb angefangen liegen geblieben sind. Was auch noch vielleicht interessant oder erwähnenswert ist, was von Vorteil ist, ist dass so ein Coaching-Tag halt nicht Vollzeit ist. Also heute haben wir Coaching, da können wir irgendwie nicht an irgendwelchen anderen Themen arbeiten, sondern dass sich diese zwei Termine, also diese Learning Hour und Ensemble Working in den normalen Arbeitsalltag integrieren lassen.

Das sind eben ein plus zwei Stunden, also typischerweise gerne vor- und nachmittags. Die Learning Hour vormittags, das Ensemble Working nachmittags, so dass ein Team, was gecoacht wird, selbst an einem Coaching-Tag noch Zeit für das Tagesgeschäft hat. Wenn da irgendwas mal brennt, kriegt dass das Team trotzdem hin. Und diese zehn Einheiten, die verteilen wir im Normalfall auf fünf bis sechs Wochen. Also drei Coaching-Tage pro Woche, das wäre schon relativ viel. Wir versuchen so zwei Coaching-Tage die Woche anzustreben.

Ralf: Was das Integrieren in den Arbeitsalltag betrifft: wir arbeiten ja auch nicht nur am Projekt-Code, sondern wirklich an den echten Aufgaben, die das Team auch ohne Coaching in Angriff nehmen würde. Und dadurch ist es sowieso jetzt kein harter Bruch. Klar, wir nehmen da gewissermaßen Tempo raus, weil wir ja versuchen Dinge anders, mit anderer Methodik irgendwie anzugehen und umzusetzen. Aber wir reißen jetzt nicht das Team aus dem Arbeitskontext und machen irgendwie was ganz anderes.

Holger: Ihr habt vorhin gesprochen - Learning Hour, eine Stunde sozusagen ein Thema zu lernen und vorzustellen, sei es Testing oder Refactoring, irgendeine Technik. Das Ensemble Working, zwei Stunden mit dem Team zusammenarbeiten, heißt ja wahrscheinlich nicht nur das Team ganz alleine, sondern die Coaches haben da auch schon eine Rolle und man geht da irgendwie doch im Ensemble vor. Wie gestaltet sich das denn so? Mag das einer erklären?

Peter: Also ich glaube, auf Ensemble Working kann man mit zwei Perspektiven drauf gucken. Einmal als Werkzeug für uns im Coaching, dass wir eben mit dem gesamten Team Lernerfahrung machen, Dinge lernen. Deswegen ist es dort sinnvoll, dort mit dem gesamten Team anwesend zu sein. Und natürlich ist es dort auch sinnvoll zu sagen, wir rotieren dort durch, dass nicht irgendwie einer aktiv und der Rest irgendwie passiv ist und zuguckt. Deswegen nutzen wir das Ensemble Programming auch in den Ensemble Working Sessions als Werkzeug fürs Coaching selber. Versuchen aber auch, oder vielleicht gar nicht versuchen, sondern eher, dass die Teams auch feststellen, dass das gemeinsame Arbeiten ihnen generell einfach hilft.

Gerade bei Dingen, die eben nicht ganz so trivial sind. Das heißt also für die Zuhörenden, denen Mob oder Ensemble Working vielleicht als solches nicht bekannt ist: Es ist im Prinzip - Tim, du sagst immer so - Pair Programming hoch drei, trifft es eigentlich ganz gut. Wir alle arbeiten am Code, eben nicht im Pair, sondern im Mob oder im Ensemble.

Das heißt, typischerweise haben wir dort auch einen Typisten, der die Ideen des Ensembles in Code überführt und das Ensemble, was die Richtung vorgibt. Je nachdem, wie groß oder mit welchem Team wir unterwegs sind, haben wir dann auch noch mal eine Navigatoren-Rolle. Muss aber nicht sein, auf jeden Fall einer ist immer aktiv als Typist und diese Rolle wird, wie beim Pair Programming auch, durchrotiert allerspätestens nach 10 Minuten. Das ist aber schon eine relativ lange Zeit, eher so 5 bis 8 Minuten. Relativ häufig geben uns die Teams dann anschließend auch Feedback, dass wir hier, so wie wir im Coaching vorgegangen sind, so wollen wir eigentlich auch weiter im Projekt an bestimmten Aufgaben arbeiten. Das heißt, dass Ensemble Working als Werkzeug auch mitnehmen, also außerhalb des Coachings auch zum Einsatz bringen.

Holger: Heißt dass dann, ich als Typist bin so als Driver unterwegs oder ist das doch vom Vorgehen ein bisschen anders? Ralf hat schon das Mikro in der Hand.

Ralf: Ja guter Punkt, ich wollte auch gerade noch ergänzen. Eigentlich ist der Typist so ziemlich die einfachste Rolle, weil da kann man sich ganz drauf konzentrieren, einfach das, was das Team irgendwie als nächstes angehen will, noch in Code zu übersetzen. Aber das schöne beim Ensemble ist ja, dass wirklich alle aktiv mitmachen. Alle sind jederzeit involviert, diskutieren, sprechen über Lösungsansätze oder um was es eben gerade geht. Der Typist, wie gesagt, tippt dann sozusagen noch ein. Alle sind da involviert, können sich einbringen, auch rollenübergreifend. Also man kann da eben auch einen Fachexperten oder egal wen, der etwas beitragen kann, mit dazu nehmen.

Als Coach muss man im Prinzip „nur schauen“, dass das Ganze funktioniert. Dass es läuft, indem man Fragen stellt, indem man ein bisschen Struktur reinbringt. Sozusagen ein bisschen auch die Rahmenbedingungen schafft. Im Coaching ist das eben auch ein sicherer Raum, in dem man sich bewegt, um einfach Dinge mal auszuprobieren - einfach mal paar Schritte in eine Richtung zu gehen und vielleicht auch zu sagen: Nee, war nicht das Richtige, wir gehen wieder zurück. Das sind Themen, die wir da eben auch vermitteln wollen. Ja, und im Idealfall, und das ist aber auch oft die Beobachtung, fließt es dann eben auch in den Arbeitsalltag letztendlich ein und geht ein bisschen darin auf.

Peter: Ralf, weil du gerade sagtest, auch rollenübergreifend, das ist für mich tatsächlich so einer der wichtigen Punkte: Das war eine Story ‚ziehen‘, die wir bearbeiten und halt alle Leute, die notwendig sind, um diese Story umzusetzen, dabei sind. Das eben nicht passiert: Ja, wir sind eigentlich quasi fertig, aber der Datenbankmensch muss noch irgendwas tun.

Sondern dass wir sagen, wir arbeiten gemeinsam an der Story. Wir splitten nicht irgendwie die Aufgaben und führen die dann wieder zusammen. Was nämlich auch so ein Punkt ist, wo ich immer wieder gerne drauf hinweise, dass dieses Aufsplitten und Zusammenführen von Arbeit halt auch Aufwände mit sich zieht und das gerne übersehen wird.

Mal sowas wie Wissensverteilung, was dann automatisch passiert oder auch eine gegenseitige Vertretung. Also das kommt ja alles noch mit dazu, dass das Team als solches in der Lage ist, sämtliche Aufgaben auch erledigen zu können und nicht irgendwelche Spezialaufgaben, irgendwie sowas. Wir würden gerne ausliefern, aber der, der weiß, wie der Build funktioniert, der ist gerade nicht da. Wir müssen warten, dass der wieder zurück ist. Sondern, dass so ein Team als solches immer handlungsfähig ist, egal welche Aufgaben tatsächlich gerade aktuell anstehen.

Holger: Und es geht ja darum: das gemeinsame Lernen. Wir sitzen als Gruppe und lernen alle zusammen, was vielleicht auch, um es nochmal zu sagen, bei der Learning Hour wird es ja auch schon so gemacht. Dass natürlich auch Übungsaufgaben da sind, die im Ensemble gelöst werden, also im Ensemble Programming dann gemacht wird. Nicht dass sozusagen - jetzt wird eine Aufgabe vorgestellt, dann gehen wir alle in kleine Räume und lösen da irgendwas, sondern das wird halt in der ganzen Gruppe als gemeinsames Lernen betrieben. Das ist ja auch so ein bisschen die Philosophie, die dahinter steckt.

Peter: Die Learning Hours sind immer ähnlich oder gleich strukturiert nach dem 4C. Das heißt, es ist immer ein Stück weit auch Theorie mit drin. Also dieser Concept-Teil, wo in der Theorie was vermittelt wird oder vielleicht nochmal geschärft wird. Und immer auch ein Concrete-Teil, wo an einer Übungsaufgabe schon mal das Gelernte oder Aufgefrischte nochmal verprobt wird. Aber halt eben nicht in dem Projektkontext mit den sonstigen Schwierigkeiten, die dort eben auftauchen. Also meistens ein ganz, ganz einfaches Beispiel, wo die Fachlichkeit entweder völlig trivial ist oder eben bekannt ist, wo der Fokus tatsächlich genau auf diesem einen Schwerpunkt dann auch liegt, der in dieser Learning Hour vermittelt wird. Also Learning Hour, klingt so nach einer Stunde Theorie, ist es aber halt nicht. Ich würde sagen, so der Theorieanteil ist so ein Drittel bis ein Viertel der Learning Hour und der Rest ist eben - also der Schwerpunkt liegt eben im Ausprobieren.

Holger: Ausprobieren und sozusagen nicht die Leute mit Informationen ‚sandstrahlen‘ nannte das mal ein ehemaliger Geschäftsführer so schön nach dem Motto: Wenn ich die einfach mit Information zuschütte und danach wissen sie gar nicht mehr, was sie machen können, dürfen, tun, sollen. Okay, schauen wir doch mal aufs Coaching an sich. Also aus ziemlich sicherer Quelle weiß ich ja, dass ihr schon insgesamt über 20 Coachings gemacht habt - also bei unterschiedlichen Teams. Manchmal ja auch sogar ein zweites Mal Coaching. Könnt ihr denn sagen - und ich frag mal einfach auch Tim: Gibt es da so ein Muster bei den Coachings nach dem Motto, das ist uns aufgefallen? Das sind so klassische Themen, die wir dann ansprechen und die wir dann als Learning Hour oder als Themen im Coaching adressieren?

Tim: Also wir haben ja auch mal so ein bisschen geschaut, was waren die Learning Hours, die wir am meisten verwendet haben. Und ich würde sagen so alles, also viel zum Thema Test, also automatisiertes Testen, Unit Testing - das waren glaube ich so die, an die ich mich am meisten erinnere. Hier und da glaube ich war es auch mal ein Refactoring. Oder auch mal ein Team mit einem Schwerpunkt auf Refactoring. Aber ich glaube viel in Richtung Testing.

Holger: Noch von den anderen beiden Einblicke, was so beliebte Themen sind?

Ralf: Also was immer mit drin steckt - aber manchmal auch ganz explizit als Thema - ist eben Zusammenarbeit. Wie wir es jetzt gerade schon am Ensemble veranschaulicht haben, ist oft eben auch das Thema Know-how-Transfer, dann auch irgendwie ein Kernthema. Wo wir sagen: Ja, wir wollen auch wirklich schauen, wie wir euch übers Coaching hinaus in so einen Modus kriegen - in eine Zusammenarbeit bekommen, dass eben kein expliziter Know-how-Transfer zum Zeitpunkt X noch mal notwendig ist, sondern dass das ganz automatisch im Team passiert. Das hatten wir jetzt gerade auch, glaube ich, bei den letzten Teams ein paar Mal.

Peter: Also was mir so als Pattern im Kopf ist, ist, dass wir mehrere Teams hatten, die gerne Dinge an ihrer Software gerne geändert hätten, aber ihren Tests nicht getraut haben oder es waren keine Tests da. Wo für mich so dieses Pattern erkennbar war, okay, wir haben irgendwas, wir würden gerne hier was ändern. Aber um es ändern zu können, müssen wir erstmal irgendwie dafür sorgen, dass wir es mit Tests abgesichert bekommen.

Und dann ist die Folgefrage, wie könnt ihr zukünftig verhindern, dass ihr Code habt, der nicht oder schlecht durch automatisierte Tests abgesichert ist. Das heißt, für mich war diese Pattern sowas wie Legacy Code mit keinen oder nicht zuverlässigen Tests. Erstmal diese Absicherung hinzukriegen, dann den Umbau als solchen vorzunehmen und eben auch dort mit dem Fokus der kleinen Schritte - eben nicht zu sagen, okay, wir reißen jetzt hier das große Loch auf und wir sind jetzt ein halbes Jahr dann eben nicht mehr auslieferungsfähig. Sondern ein Refactoring, das ist eigentlich auch die Idee des Refactorings, eben in kleinen Schritten vorzunehmen, dem Team auch Werkzeuge mitzugeben: Tipps, Tricks, Kniffe, wie sowas funktionieren kann, wie man eben auch den Umbau am offenen Herzen eben durchführen kann, trotzdem immer auslieferungsfähig bleibt und dann so ein bisschen auch der Ausblick eben, Ralf hat es vorhin auch erwähnt, so Richtung testgetriebenen Entwicklung.

Also, wie könnt ihr zukünftig verhindern, dass irgendwie heißt, ja, wir sind fertig - für Tests haben wir jetzt keine Zeit mehr. TDD ist ja nicht nur dazu da, Tests zu schreiben, sondern es ist ja eigentlich eine Designhilfe, was mich unterstützt, aber als Nebenprodukt ich eben im Normalfall gut automatisierte Tests habe, die es dann wert sind, beizubehalten, um das Produkt vor Regression zu schützen.

Holger: Was ich mich noch frage, ist genau, das Team zu coachen in der Entwicklung im Projekt. Nun es ist ja so, dass bei Atruvia schon sehr viel Java und Spring Boot vorherrscht. Nach dem Motto, man hat schon einen einheitlichen Technikstack. Fachlich ist es ja aber schon immer was anderes, was die Teams dort machen. Meine Frage wäre, wie habt ihr das so wahrgenommen? Na ja, man ist dann auch Coach, aber die arbeiten halt natürlich vielleicht an Sachen, die man nicht so richtig versteht. Man kommt da ja rein. Wie seid ihr da so mit umgegangen? Oder habt ihr vielleicht auch noch Erfahrungen gehabt mit anderen Programmiersprachen, Frameworks? Nach dem Motto, wir machen ein bisschen ganz was anderes.

Peter: Also ich glaube, generell kann man erst mal sagen, das, was wir in den Coachings vermitteln, ist erst mal frei von von Programmiersprachen. Wir haben jetzt schon unterschiedlichste Teams auch gehabt. Java, JavaScript, ein Cobol-Team hatten wir, wobei das auch ein Mix aus Cobol und Java und der Schwerpunkt im Coaching selber. Dann doch eher in der Java-Ecke. Ja, die Fachlichkeit ist natürlich immer eine Herausforderung, weil meistens, also mir geht es relativ häufig so, dass ich am Ende so halbwegs dann verstanden habe, was die Fachlichkeit ist. Und es ist natürlich immer auch schwierig, dann zu unterstützen und zu beraten, wenn man die Fachlichkeit nicht ganz überschaut hat.

Aber der Schwerpunkt liegt ja auf dem Vorgehen. Und die Fachexperten sind und bleiben natürlich die Leute aus dem Team. Nichtsdestotrotz muss man ein gewisses Verständnis davon haben, was die Fachlichkeit angeht. Was uns, glaube ich, hilft, ist, dass wir am Anfang im Kickoff-Workshop uns nicht nur die Architektur zeigen lassen, sondern auch die Anwendung als solches eben aus Sicht des Nutzenden der Anwendung. Also mir hilft das immer, um damit ein halbwegs gutes Verständnis der Fachlichkeit zu Beginn zu haben. Aber nichtsdestotrotz, also wir haben schon Teams mit hochkomplexen fachlichen Anforderungen. Das ist schon immer eine Herausforderung in den Coachings.

Ralf: Gleichzeitig muss man ja auch sagen, so ein frischer Blick von außen, und wir waren ja auch jetzt, Holger, du hast es gesagt, schon in einigen Teams unterwegs, der ist ja auch oft hilfreich. Und wenn dann das Team einem Dinge erklärt, dann wird dem Team selbst auch manches noch mal klarer, wenn man es dann mal versucht, in Erklärung zu fassen. Genau, also wir müssen ja da auch gar nicht alles wissen, auch technisch natürlich nicht. Wir kommen nicht mit einer goldenen Lösung um die Ecke, sondern wir wollen zusammen Dinge ausprobieren. Und es ist, glaube ich, ganz wichtig, dass wir da Fragen stellen, Dinge ein Stück weit klären, aber dann eben auch ins Doing kommen und einfach mal zusammen Dinge ausprobieren, ohne Angst, dass da jetzt was kaputt geht. Im schlimmsten Fall dreht man es mal wieder zurück und hat eben viel bei gelernt. Das ist eigentlich die Hauptsache. Und ja, da kann auch so dieser frische Blick und die in „dummen Fragen“ manchmal ganz hilfreich für alle sein.

Holger: Also höre ich da auch raus, man muss halt auch eine Coaching-Haltung haben. Also beraten heißt ja so, ich sage dir, der Steuerberater sagt dir, so genau geht das. Und an der Stelle, wie wir es jetzt lösen, weiß man es ja jetzt nicht so genau. Aber im Team ist ja durchaus da Kompetenz da. Und manchmal ist es halt wichtig, neues Wissen einzustreuen und den Leuten zu helfen, da in die richtige Richtung zu kommen. Und das ja auch irgendwie im Team zu enablen, dass wir halt als Gruppe darüber nachdenken, wie lösen wir das jetzt eigentlich. Okay, genau. Zu den Learning Hours, also unter sammancoaching.org gibt es ja einen ganzen Haufen an Learning Hours, die verschiedenste Themen berücksichtigen. Ich glaube, bei Atruvia, ihr habt das sozusagen nochmal umgesetzt, und es waren so um die 30 Stück. Wie habt ihr das noch gemacht? Ist das dann irgendwie über irgendein Board? Oder wie teilt ihr dann die Aufgaben? Kann da vielleicht noch jemand technisch was zu sagen?

Peter: Ja, also auf sammancoaching.org findet man die Learning Hours. Einen großen Katalog, der auch stetig wächst und jetzt auch die letzten zwei Jahre wirklich immens gewachsen ist. Wo wir angefangen haben, sah der noch deutlich übersichtlicher aus, der Katalog. Wir haben halt begonnen, das für uns durchzulesen, die Learning Hour für uns nochmal: Was ist dort beschrieben? Was bedeutet das für uns? Vielleicht nochmal in den eigenen Worten zu beschreiben.

Typischerweise steht auf so einer Learning-Hour-Beschreibung dann auch eine Kata als Empfehlung drauf, die man in dieser Learning Hour mit diesem Inhalt durchführen kann, wo wir auch vielleicht das eine oder andere Mal eine andere Kata verwenden. Das heißt, wir pflegen diesen Katalog nochmal für uns selber. Auch deswegen, weil wir ein paar Dinge haben, die wir noch erweitert haben, sowas wie bei welchen Schmerzen hilft diese Learning Hour vielleicht ganz gut oder bei welchen Erkenntnissen. Was ist vielleicht auch eine gute Vor- oder Nachgänger Learning Hour, haben wir nochmal festgehalten.

Und ja, wir haben das ganze Konzept begonnen anzuwenden, als wir in der Corona-Pandemie waren. Das heißt, wir haben von Anfang an alles auf Remote-Arbeit ausgelegt gehabt und haben uns dort eben - wir nutzen nicht Miro, sondern Concept Board - Board-Templates angelegt, wo die Inhalte drauf sind, sodass wir die Inhalte gemeinsam mit dem Team dann auf dem Board bearbeiten können. Zum Teil ist es dann auch so, dass die Teilnehmenden dann auch Sticky Notes dann auf dem Board platzieren. Also gerade so bei diesen Connect-Teilen oder Conclusion, also dieser Connect-Teil ist so die Möglichkeit, irgendwie innerhalb von fünf Minuten sich auf die Learning Hour fokussieren zu können und der Conclusion-Teil nochmal ein kleiner Abschluss, eine kleine Retro. Ja, und dort haben die Teilnehmenden eben die Möglichkeit, nochmal Sticky Notes auf dem Board zu platzieren. Also wir haben für jede Learning Hour dann so ein Template und kopieren das dann in das Verzeichnis für das laufende Coaching für das Team. Kopieren wir es dann zum bearbeitbaren Board dort hinein.

Ralf: Und man muss auch noch sagen, die frei verfügbaren Learning Hours die es gibt, die sind auch schon sehr gut beschrieben, sehr umfangreich von den Themen. Also ganz am Anfang haben wir wirklich auch rein mit diesen Learning Hours, also mindestens mal im ersten Coaching, alles abdecken können. Natürlich, wenn man dann über die Zeit Erfahrung sammelt und vielleicht das ein oder andere noch genauer, noch spezifischer auf einzelnes Coaching und ein einzelnes Team zuschneiden möchte, dann kann man das tun, aber man kommt da wirklich auch mit dem, was da im Katalog schon drin ist, sehr gut zurecht. Man muss da nicht zwingend eigene neue Inhalte noch erfinden.

Holger: Dann wäre meine Frage noch: ihr habt das jetzt schon zwanzigmal, mehr als zwanzigmal ein Coaching durchgeführt. Wie war denn so das Feedback vom Coaching? Was habt ihr da so für Stimmen gehört? Habt ihr vielleicht auch später noch was gehört, wie Teams mit dem Coaching umgegangen sind? Wie war es mit der Nachhaltigkeit des Coachings? Das war ja auch durchaus ein Thema nach dem Motto, na ja, Schulungen sind gut, aber das immer umsetzen ist halt immer ein bisschen schwierig und dann wird's tricky und gerade dann verlässt man die Leute. War das mit dem Coaching dann jetzt anders geworden? Wie würdet ihr da drauf blicken?

Ralf: Also ich würde mal sagen ja. Wir haben jetzt nicht den Vergleich. Wir haben nicht das Feedback in gleicher Art und Weise nach den Schulungen oder Dojos irgendwie gemacht. Dann war es eher so ein bisschen Gefühl oder einzelne Rückmeldungen von Teilnehmern. Wir haben jetzt beim Samman Coaching gesagt, wir machen Feedback am Ende des Coachings, aber auch ein zweites Feedback mindestens drei Monate nach dem Coaching. Und ja, das war durchaus erfreulich. Also wir haben an sich schon durchweg positives Feedback direkt nach dem Coaching. Und es ist in der Regel bei den allermeisten Teams mindestens genauso gut geblieben oder sogar besser geworden, wenn wir später nochmal dort aufschlagen und nochmal so ein bisschen Rückschau machen und nochmal eben ein zweites Feedback einholen. Also das heißt für uns, es scheint zu funktionieren.

Es ist wirklich so, dass die Inhalte nachhaltiger vermittelt werden. Und ja, wenn man mit den Leuten auch darüber spricht, was sie dann tatsächlich einsetzen noch, merkt man, dass da vieles auch einfach weiterhin im Einsatz geblieben ist oder vielleicht sogar sich noch verstärkt hat.

Peter: Und das ist ja der ganz wesentliche Aspekt. Das ist auch das, was Emily auf ihren Seiten immer wieder beschreibt. Also dass es zu einer Verhaltensänderung kommt, auch wenn der Coach nicht mehr Bestandteil des Teams ist oder nicht mehr im Team mitwirkt. Also das ist uns ja der allerwichtigste Punkt, dass wir sagen, das ist ja das, was wir erreichen wollen, dass sich Dinge für das Team verändern, auch wenn wir nicht mehr in dem Team drin sind.

Tim: Und ich kann mich an mehrere Feedback-Gespräche erinnern, wo das Ensemble Programming explizit genannt wurde, dass eben die Teams diesen Modus neu kennengelernt haben im Coaching und dann aber auch für bestimmte Themen, das gerne darauf zurückkommt. Das ist nicht als Default-Arbeitsmodus, aber schon immer, immer das mal wieder verproben oder immer mal wieder darauf zurückkommen, um damit Wissen zu verteilen, neue Themen anzugehen und so weiter.

Ralf: Genau, auf den Punkt wollte ich auch hinaus. Ja, wie du gesagt hast, es ist dann vielleicht einfach nur häufigeres Pair Programming oder ja, es muss nicht das Ensemble sein, darf es natürlich gern auch, aber das ist auch durch die Bank eigentlich eine Beobachtung, dass das einfach zunimmt in Folge des Coachings.

Holger: Okay, also schon Veränderungen, die im Team dann auf Dauer passiert sind. Vielleicht nochmal noch eine Frage an dich, Tim. Es gibt ja, also Emily Bache hat sozusagen dieses Samman Coaching erfunden, designed, gemacht. Es gibt auch noch die Samman Society, die sich irgendwie versucht, das Coaching weiter fortzuführen. Kannst du darüber noch ein bisschen was berichten, was man da sozusagen vor hat mit dem Coaching?

Tim: Genau, es gibt die Samman Coaching Society, also einen Zusammenschluss erst mal von technisch agilen Coaches. Peter ist ja auch Mitglied der Samman Society und das Ziel der Society ist erst mal für technische Coaches Mittel bereit zu stellen, eben diese Vorlagen, das Learning Hour Repo oder auch die Learning Hour Webseite, um dort die Mittel zu haben, um mit Teams zu arbeiten. Also ein bisschen so, wie wir das vielleicht als Agile Coaches kennen, also so den Retromat und so einfach so Handwerkszeug, so dass ich halt auch bei einem Team aufschlagen kann und auch so eine Idee hat, wie kann ich mit euch Coaching machen und ein bisschen auch die Frage, was ist denn technisches Coaching eigentlich, weil das ja auch manchmal noch so unklar ist. Jetzt kommt ein technischer Coach hier, arbeitet mit dem Team. Was bedeutet das eigentlich? Und da bietet das Samman Coaching erstmal eine Struktur, einen Vorausblick. So können wir es machen.

Holger: Gut, also haben wir durchaus ein Coaching, das zur Veränderung in Teams geführt hat, auch zu einer Zufriedenheit geführt hat. Über die Seite hat man sicherlich auch noch mal die Gelegenheit reinzuschauen, was ist denn das eigentlich, Samman Coaching. Ich werde das auch entsprechend noch als Link zu diesem Podcast dazu tun, dass man da auch mal drauf schauen kann, falls man nicht weiß, wie man Samman genau buchstabiert, aber es ist auch relativ einfach. Würdet ihr den anderen Unternehmen das empfehlen? Fast schon eine rhetorische Frage. Oder was sollten andere Unternehmen beachten, wenn sie vielleicht Coaching einführen? Das ist vielleicht ein bisschen ‚trickier‘ - „Nach der Samman-Methode“ das muss man auch immer sagen. Es heißt technisches Coaching nach der Samman-Methode. Sozusagen dieses Samman-Coaching, also ich sag nicht ist lizenziert. Also das ist nochmal eine andere Frage. Aber man kann auch mal sagen, wie Coaching nach der Samman-Methode, alles ist gut. Könnt ihr noch anderen was mitgeben, nach dem Motto, wenn man das einführen möchte, würde ich euch raten, dieses oder jenes zu tun. Oder auch nicht.

Peter: Also die erste Frage war ja, ob wir es empfehlen können. Ich glaube, das können wir ohne schlechtes Gewissen zu haben, absolut, voll und ganz unterschreiben. Es ist ein Stück weit natürlich zeitaufwändig. Es skaliert jetzt natürlich nicht so wie eine Schulung, wo ich irgendwie vielleicht 20 Leute reinsetzen kann. Ich brauche eine gewisse Zeit auch für Vorbereitungen. Also wir sagen, es ist das Beste, was wir bislang kennen, um Teams aufs nächste Level zu bringen. Teams zu unterstützen, besser zu werden. Kennen wir jetzt nichts, was besser geeignet ist.

Was wir im Gespräch mit anderen Coaches gehört haben, ist, dass es zum Teil auch solche Ansätze gibt, in so einem Tandem in Teams reinzugehen. Das heißt, mit einem Agile Coach und einem Technical Agile Coach, dass auch solche Dinge vielleicht nochmal berücksichtigt werden. Wie da klemmt's im Vorgehen. Haben wir in manchen Teams auch gesehen, dass es halt öfter mal auch eben nicht nur die rein technischen Dinge sind, die nicht gut funktionieren. Das ist sicherlich nicht verkehrt, wenn man dann jemand zumindest mal zur Hand hat, der dort auch unterstützen kann. Ja, also wir hatten auch zu Beginn mal überlegt, ob wir nicht für zwei, drei Sprints mal Vollzeit in so ein Team reingehen zur Unterstützung. Das wäre natürlich noch zeitlich aufwendiger. Insofern ist das vielleicht so der gesunde Mittelweg, Samman Coaching. Emily sagt, man kann zwei bis drei Teams parallel coachen als einzelner Coach, wobei drei parallel schon absolut herausfordernd sein dürfte. Machen wir ja nicht.

Also ich glaube Vorschlag ist: einfach mal anfangen und ausprobieren, wobei ich sage mal, das ist so am Anfang ist es so wie vermutlich der der Lehre im ersten Schuljahr. Man muss erst mal das ganze Material sichten, sich einen Überblick verschaffen. Am Anfang ist es ein relativ großer Aufwand als Coach oder ein deutlich höherer, wie dann später zunehmend. Also man wird merken, wenn man so das zehnte Team coacht oder das zehnte Team hat, was man zum ersten Mal coacht, greift man natürlich auch vieles zurück, was man davor schon ausgearbeitet und verwendet hat. Also gerade so die Coachings dann, wo wir Teams hatten, die wir zum zweiten Mal gecoacht haben, haben wir wieder gemerkt, okay, dann fällt halt wieder Aufwand an. Größerer Aufwand, wo wir vielleicht weitergehendes, weiterführendes Material, sichten, ausarbeiten müssen.

Also der Aufwand am Anfang ist vielleicht, also das ist vielleicht mein Tipp, den Aufwand am Anfang nicht zu unterschätzen, bis man zum ersten Mal reinkommt, das erstes Team zu unterstützen. Und vielleicht auch, dass der Tipp, dass eben nicht annehmen, dass das so bleibt, dass jedes Coaching gleich aufwendig ist, wie das erste Coaching.

Ralf: Mein Tipp wäre noch nicht zu viel in ein Coaching packen. Wir haben am Anfang glaube ich etwas mehr Themen auch in so ein Coaching packen wollen, sage ich mal, als vielleicht sinnvoll war. Und mittlerweile fokussieren wir uns in der Regel auf zwei Hauptthemen. Besser ist es tatsächlich auch, etwas langfristiger zu denken. Nach dem Coaching ist ein Stück weit vor dem nächsten Coaching. Und das Team braucht aber auch einfach Zeit, um das Ganze im Arbeitsalltag noch weiter in die Routine zu bringen. Also die gehen jetzt auch nicht aus dem Coaching raus und können alles in Perfektion, sage ich jetzt mal, sondern es geht dann eben weiter. Und dafür braucht das Team auch ein bisschen Zeit. Ja, also die Methodiken sind dann trotzdem noch relativ frisch und neu. Also das sollte man dann insgesamt auch berücksichtigen und den Teams diesen Rahmen geben und dann eben langfristig denken und durchaus auch Teams immer mal wieder coachen.

Tim: Vielleicht, was mir auch noch einfällt gerade, die Learning Hours nicht zu voll packen. Ich glaube, wir hatten häufiger mal die Befürchtung, oh nein, was machen wir, wenn wir mit dem Inhalt quasi durch sind, zu wenig haben und dass es nicht passiert.

Holger: Das stimmt. Wir dachten manchmal, oh ist das viel zu einfach. Dann sind doch noch interessante Probleme aufgekommen. Und wenn ich mich richtig erinnere, ist es ja so, dass Emily ja auch Learning Hours als Video anbietet oder auch irgendwie vordefiniert als Board, die man sich sozusagen kaufen kann für relativ wenig Geld. Weil wir auch gemerkt haben, dass die Vorbereitung schon noch ein bisschen Vorarbeit braucht. Das erstellt sich nicht von alleine, wie das so schön heißt.

Peter: Vielleicht, Holger, ein guter Hinweis. Also es gibt so Guided Learning Hours, vielleicht die einfach mal ausprobieren. Es gibt auch zahlreiche kostenlose Guided Learning Hours, die man einfach verwenden kann. Es gibt dann noch mal, wenn man sagt, ich hätte gerne diese Guided Learning Hour, aber in einer anderen Sprache. Da hat Emily dann auch noch mal kostenpflichtige Angebote. Aber das ist auf jeden Fall ein guter Weg, um vielleicht auch mal reinzuschnuppern, wo der Aufwand dann doch noch mal überschaubarer ist, wie das Material erst mal selber auszuarbeiten.

Holger: Gut, wir haben auch schon 50 Minuten über Samman Coaching gesprochen. Liebe Zuhörer, ich hoffe, ihr habt einen guten Einblick gekommen, was Summer Coaching ist und wie das auch geholfen hat. Vielleicht eine Idee, das mal im eigenen Unternehmen auszuprobieren. Wenn man technischer Coach ist, ist das, und da spreche ich auch aus Erfahrung, ein super Hilfsmittel, um Teams da auch zu einer besseren technischen Exzellenz zu bringen und ihnen zu helfen. Und das wirklich auch an ihren Code. Gibt keine Ausrede nach dem Motto, das läuft bei uns nicht. Nee, jetzt werden wir das mal ausprobieren. Und es war nie immer leicht, aber wir sind auch nicht komplett gescheitert, manchmal gegen dann Dinge doch, wenn man sich mal zusammensetzt und das anwendet.

Insofern, Ralf, Peter und Tim, vielen Dank. Kleiner Ausblick noch, wen es interessiert. Es gibt ja immer die XP Days im Oktober. Eine sehr interessante Konferenz. Gerne mal da sein. Ich hoffe, der Podcast kommt vorher raus. Peter, Tim und mich werdet ihr dann da auch sehen mit Vorträgen und Workshops. Insofern sieht man sich vielleicht wieder und dann bleibt mir nur noch zu sagen, viel Dank und auf Wiedersehen. Und wir sehen uns die Tage. Bis denn!