Remote Mob Programming

Stefan Tilkov: Hallo und herzlich Willkommen zu einer neuen Episode des INNOQ-Podcast. Heute zu einem, wie ich finde, extrem coolen Thema, von dem ich jetzt im Moment gerade jedem erzählen muss, weil ich es so absolut abgefahren finde, und zwar zum Thema Remote Mob Programming. Dazu habe ich drei Gäste da, nämlich Jochen, Simon und Martin. Hallo!

Jochen Christ, Simon Harrer, Martin Huber: Hallo, Stefan!

Stefan Tilkov: Und wie immer würde ich euch bitten, euch am Anfang ganz kurz vorzustellen. Jochen, fang doch an.

Jochen Christ: Mein Name ist Jochen Christ, ich bin Senior Consultant bei INNOQ seit zwei Jahren. Insgesamt bin ich jetzt schon seit zwölf Jahren im Consulting tätig. Immer beim Kunden vor Ort und seit einem halben Jahr mache ich jetzt Remote Mob Programming und das fühlt sich gut an, darüber möchten wir heute berichten.

Simon Harrer: Ich bin jetzt seit einem Jahr dabei, mein Name ist Simon Harrer und ich bin auch Senior Consultant. Also Remote Mob Programming fühlt sich super an, ich will nie wieder anders arbeiten und ich freue mich, euch heute berichten zu dürfen.

Stefan Tilkov: Und Martin.

Martin Huber: Mein Name ist Martin Huber, ich bin schon seit fast zehn Jahren bei INNOQ, also in einem halben Jahr ist es dann auch schon so weit. Ich bin jetzt auch seit einem halben Jahr in dem Remote Mob und finde es auch sehr cool. Und ich bin auch schon relativ lange oder etwas länger als Jochen im Consulting-Business unterwegs.

Stefan Tilkov: Alles klar. Gut, vielleicht fangen wir einfach kurz an, indem ihr ein bisschen von dem Projektkontext erzählt, in dem das Ganze entstanden ist. Simon, möchtest du mal dazu starten?

Simon Harrer: Wir haben zu dritt angefangen bei einem Projekt beim Kunden, im August letzten Jahres. Und in dem Projekt geht es praktisch im E-Commerce-Bereich darum, dass wir ein komplettes INNO-Team gestellt haben, ein Entwicklungsteam, für eine Vertikale in so einer E-Commerce-Customer-Journey. Der Product-Owner ist remote, das ist eine Frau, die in in Hamburg wohnt und der Kunde selbst ist in Stuttgart. Und wir wohnen eben alle irgendwo in der Nähe von Nürnberg, mehr oder weniger nah bei Nürnberg. So ist das Projekt irgendwie entstanden. Wir fanden das eine spannende Herausforderung, gerade weil es so eine zentrale Komponente in diesem E-Commerce-Projekt war im Order-Management-Bereich. So ist das Ganze gestartet, wir mussten dieses Projekt übernehmen, wir sollten dafür sorgen, dass das alles korrekt und super entwickelt wird.

Stefan Tilkov: Jetzt ist remote-Arbeit bei uns ja nichts Ungewöhnliches, das machen wir in vielen Projekten. Aber ihr habt das irgendwie anders gemacht. Jochen, möchtest du kurz starten und erzählen, was euch dazu bewegt hat, das anders zu machen?

Jochen Christ: Ja genau, und zwar hat das Projekt begonnen und wir waren alle zusammen die erste Woche beim Kunden und haben uns überlegt, wie wir denn das Projekt jetzt umsetzen. Wir hatten so die ersten Architekturdiskussionen gehabt, die fachlichen Diskussion und irgendwann ging es dann los, dass wir auch den ersten Code geschrieben haben. Und am Anfang war es uns halt wichtig, dass wir die Entscheidungen, die wir ganz zu Beginn treffen, alle gemeinsam treffen und da haben wir einfach alle zusammen gecodet, das erstes Spring Boot-Projekt und die erste Datenbank aufgesetzt. Das haben wir alles zusammen gemacht und das hat sich halt gut angefühlt. Irgendwann waren dann die zwei Wochen vorbei und dann waren wir alle zu Hause im Home-Office und haben uns überlegt, wie wir jetzt weitermachen. Und da sich das gut angefühlt hat, haben wir einfach weitergemacht. Wir haben dann mit Screensharing gearbeitet und zusammen dann nach und nach die ersten Features einfach umgesetzt.

Martin Huber: Was für mich zum Beispiel auch sehr gut war, weil ich mit Spring Boot in den letzten Jahren nicht mehr so viel zu tun hatte beziehungsweise da ein relativer Neuling war, ich mit Java die letzten Jahre auch nicht mehr gearbeitet hatte. Ich hatte schon mal Java programmiert, aber es ist schon etwas länger her und das jetzt quasi in dem Team zu machen und zusammen zu tun, das war am Anfang sehr gut.

Stefan Tilkov: Ich glaube, die Assoziation zu dem Mob Programming kam von dir, Simon, kannst du dazu ein bisschen etwas erzählen, was ist denn überhaupt Mob Programming?

Simon Harrer: Es gibt eine tolle Definition von Woody Zuill – der hat das eigentlich wirklich voran getrieben und bei einer Firma eingeführt – und zwar: [All the brilliant minds work on the same thing, at the same time, in the same space on a single computer. Wortwörtlich geht das Zitat so: All the brilliant minds working together on the same thing, at the same time, in the same space, and at the same computer.] Das ist halt anders als so das klassische Arbeiten. Das heißt, normalerweise arbeitet jeder für sich, schnappt sich ein Ticket und bearbeitet das Ticket, stellt einen Pull-Request, es wird dann gereviewt und geht rein. Jeder arbeitet an seinem eigenen Rechner parallel, Tickets werden parallel bearbeitet. Und Mob Programming sagt halt, nein, alle arbeiten immer am gleichen Problem und es schauen alle auf den gleichen Bildschirm, während sie das tun. Und das ist eben eine ganz, ganz andere Art des Arbeitens.

Stefan Tilkov: Aber Mob Programming ist ja eigentlich etwas, was man bei einem Event irgendwie macht, wenn man gemeinsam in einem Raum ist. Und das ist nicht das, was ihr als euer Arbeitsmodell gewählt habt. Warum eigentlich nicht, für mich wohnt ihr ja alle im selben Ort? Also von da, wo ich wohne, aus gesehen, ist das absolut so. Das ist tatsächlich aber nicht der Fall, so nah zusammen wohnt ihr auch nicht, richtig? War das der Grund, weswegen ihr das nicht in Erwägung gezogen habt?

Martin Huber: Nein, so nah ist es dann auch wieder nicht. Also es ist mindestens, sage ich mal, eine halbe bis Dreiviertelstunde reine Autofahrt, mit dem Zug teilweise noch schlimmer. Jetzt ist der Kollege dann in der Zwischenzeit auch noch umgezogen, irgendwo in die Pampe, was man wirklich nur schwer erreichen kann. Also er hat es wirklich schwer, dann tatsächlich an einen zentralen Ort zu kommen.

Stefan Tilkov: Ok, das heißt ihr habt das offensichtlich anders aufgesetzt. Ihr habt versucht, diese Idee von Mob Programming in einem remote-Kontext umzusetzen und da müsst ihr vielleicht mal ein bisschen näher erklären, was das eigentlich jetzt bedeutet vom Tooling her. Wie geht ihr da vor?

Martin Huber: Was bei dem Kunden sowieso schon vorhanden war, weil sie auch schon so Erfahrung gesammelt haben mit vielen remote-Programmierern… Wir haben uns das Tool, das sie dort verwenden, einfach geschnappt, das ist das appear.in. Wir haben dann einen Raum bekommen und haben uns da quasi immer getroffen. Was da dann charakteristisch ist, ist eigentlich, dass da quasi die Kamera immer an ist. Oder man kann die Kamera immer anlassen, man kann aber auch den Bildschirm teilen, und man kann sozusagen so auf die Art und Weise dieses Gefühl entstehen lassen, man sei im selben Raum.

Stefan Tilkov: Vielleicht noch, es ist dann auch gleichzeitig Screensharing und das Kamerabild, nicht entweder oder, richtig?

Martin Huber: Genau. Es kann tatsächlich jeder screensharen, man kann aber immer noch sein Bild sehen. Also das ist ja, sage ich mal, nichts Neues, dass man sagt, wenn man den anderen noch sieht zu dem, was man von ihm hört, kann man viel mehr auch seine Körpersprache lesen und auch viel mehr verstehen. Und das ist in dem Fall tatsächlich wirklich sehr wertvoll. Das man das immer noch hat, dieses Gefühl, man sitzt fast am selben Tisch.

Stefan Tilkov: Okay. Und das heißt einer von euch – jetzt sage ich mal ketzerisch – arbeitet tatsächlich, einer von euch, ist in seiner IDE – Benutzt ihr eigentlich alle die gleiche IDE oder macht jeder, was er will? – Ihr benutzt alle die gleiche, aber ihr müsstet das nicht, richtig? Ihr könntet theoretisch – aber kommen wir vielleicht gleich darauf. Also: Einer von euch hat die IDE offen und bearbeitet darin den Code von was auch immer, woran ihr gerade gemeinsam arbeitet. Und wie ist die Arbeit dann aufgeteilt unter euch Dreien? Ist dieser eine, der das macht, eher stumm und die anderen beiden sagen ihm, was er tun soll oder diskutiert ihr die ganze Zeit zu dritt, wie funktioniert das?

Simon Harrer: Wir nutzen so eine Methodik aus diesem Buch „Code with the Wisdom of the Crowd“, daran haben wir uns sehr stark orientiert, wie wir das so umsetzen. Und da gibt es den Typist und den Rest-of-the-Mob. Der Typist ist sozusagen der, der das Keyboard in dem Moment hat. In unserem remote-Setting ist es halt der, der gerade Screensharing macht und der darf nur tippen. Er bekommt praktisch nur die Befehle, die Anweisungen vom Rest-of-the-Mob, aber der Typist selbst, der nimmt die Befehle entgegen und setzt sie praktisch in die IDE um. Und der Rest-of-the-Mob, das sind die, die das Problem lösen, die sich überlegen, was möchten wir jetzt als Nächstes tun? Und das sind auch die, die dann auch gleichzeitig den Code-Review durchführen, während der Typist tippt und schauen, was er tippt: Ist es das, was wir eigentlich wollten?

Stefan Tilkov: Das heißt, der Typist diskutiert auch nicht mit, der setzt auch keine eigene Ideen um? Ihr schüttelt alle den Kopf. Also nein, er macht es nicht. Der Typist ist tatsächlich – der hat eigentlich den leichtesten Job in diesem Moment, richtig? Der macht eigentlich nur, was die anderen sagen und kann hoffentlich mit seiner IDE umgehen?

Jochen Christ: Das ist ganz interessant, wir haben festgestellt, dass die Rolle Typist zu einer Phase mentaler Entspannung führt, weil man nicht denken muss, sondern einfach nur memory-muscle das heruntertippen muss, was man eh schon kann, wenn man gerade etwas tippen muss. Und wie gesagt, das ist eigentlich eine Entspannungsphase. Obwohl man derjenige ist – du hast es gerade gesagt – der arbeitet, ist es eine Entspannungsphase.

Stefan Tilkov: Ich muss mir das mal bildlich vorstellen: Also der Typist ist in seiner IDE und einer von den anderen sagt, mach mal eine neue Instanzvariable „String name“ und mach mal eine Getter dafür, was auch immer, mach mal irgendetwas Kluges, okay. Solche Dinge werden dann gesagt oder die anderen beiden diskutieren, der andere widerspricht: Das ist eine blöde Idee, Getter sind ätzend, das machen wir nicht, wir machen das ganz anders und dann einigen sie sich. Und der Typist fängt an, wenn sie sich geeinigt haben.

Martin Huber: Genau, der fängt immer an zu tippen, der macht einfach. Beziehungsweise er bekommt eine Anweisung und zwar in dem Detailgrad, in dem er es gerade braucht. Wenn man zu ihm sagt, leg eine Klasse an, dann weiß er im Idealfall, was er zu tun hat. Und wenn er das nicht genau weiß, dann sagt man ihm halt noch etwas detaillierter, was er genau tun soll. Das ist wirklich so dieses, wenn man merkt, der Typist kommt nicht weiter dann hilft man ihm halt aus. Da kann dann natürlich der Typist dann auch mal nachfragen: Ich weiß jetzt nicht genau, was soll ich machen?

Stefan Tilkov: Okay.

Jochen Christ: Die Rollen wechseln dann auch, und zwar –

Stefan Tilkov: In welchem Abstand?

Jochen Christ: Wir haben ein bisschen herumexperimentiert, verschiedene Minuten, von fünf Minuten bis zu einer halbe Stunde, glaube ich, das war so das Höchste. Und wir haben festgestellt, dass so ein zehn-Minuten-Intervall ganz gut ist. Das ist eine ganz gute Balance zwischen dem Aufwand des Handovers, das dauert ein paar Sekunden und der Häufigkeit, dass man selbst mal wieder dran ist. Wie gesagt, wir sind bei zehn Minuten gelandet, was für uns ganz gut funktioniert, also dass die Rolle Typist dann weitergegeben wird.

Stefan Tilkov: Okay. Das heißt, ihr seid zu dritt – ihr seid jetzt neuerdings zu viert, aber den größten Teil dieser Zeit wart ihr zu dritt. Und das heißt, man tippt immer zehn Minuten, dann hat man zwanzig Minuten aktive Rolle und dann tippt man wieder zehn Minuten. Ist das auch wirklich so ohne Pause? Also macht ihr das in diesen Dingen nacheinander oder macht ihr alle dreißig Minuten, zehn Minuten oder fünfzehn Minuten Pause oder so etwas oder wie funktioniert das?

Simon Harrer: Sehr gute Frage. Also am Anfang haben wir diese Pausen nicht gemacht und das hat dazu geführt, dass wir nach drei, vier Wochen, in denen wir das gemacht haben, richtig, richtig erschöpft waren. Denn man kommt in so einen Flow rein, das kann man sich fast nicht vorstellen, und man vergisst diese Pausen und das war am Schluss nicht mehr zu ertragen. Und dann haben wir dafür gesorgt, dass wir wirklich regelmäßig Pausen machen müssen. Tendenziell, glaube ich, so nach zwei, drei Durchläufen, also so nach sechzig bis neunzig Minuten; jetzt ändert es sich ein bisschen, wenn man zu viert ist.

Stefan Tilkov: Okay. Und was mich ja total interessiert, wie lange hält man das durch? Also meine persönliche, limitierte Erfahrung mit Pair-Programming ist, dass das wahnsinnig anstrengend ist. Dass ich also wirklich nach vier Stunden Pair-Programming völlig durch war und erst mal kein Bock mehr hatte, mit irgendwem zu reden, mit irgendwem irgendetwas zu machen. Ist das bei euch auch so oder haltet ihr das den ganzen Tag durch?

Jochen Christ: Wir machen das den ganzen Tag. Sechs bis acht Stunden halt. Wenn wir gemeinsam arbeiten, arbeiten wir auch im Mob. Und das ist ganz witzig, wenn wir mal alleine sind, weil die anderen halt noch nicht da sind oder schon weg sind oder im Urlaub sind, dann will man gar nicht mehr arbeiten, weil man sich denkt, wenn ich jetzt code, mache ich das überhaupt richtig und was denken denn die anderen? Oder muss ich denen das auch noch erklären, was ich gemacht habe?

Stefan Tilkov: Der Borg hat dich assimiliert.

Jochen Christ: Ja, genau.

Stefan Tilkov: Okay. Ihr müsst mir noch erklären, wie dieser Übergang funktioniert. Also jemand ist zehn Minuten zugange und tippt. Und es ist ja nicht so, das habt ihr vorhin schon gesagt – nein, das habt ihr eigentlich nicht gesagt. Ich weiß es, weil wir vorher schon darüber gesprochen haben. Erklärt doch mal, wie das funktioniert nach diesen zehn Minuten.

Martin Huber: Simon hat sich da angestrengt, ein kleines Tool zu bauen für uns, das uns da ein bisschen hilft. Das hat er dann auch in Go geschrieben, ich glaube, weil er einfach Interesse daran hatte, das zu bauen. Das ist unsere „Mob-Tool“, das haben wir dann alle installiert, da kann man dann einfach einen Befehl eingeben, mob start. Wenn man dann quasi in einem der Projekt-Verzeichnisse ist, dann gibt man mob start ein, gibt noch eine Zeit an, eben die zehn Minuten, und dann fängt das Ding an. Was es dann macht, ist quasi einen Branch anzulegen, einen Mob-Session-Branch, der dann sozusagen immer weiter verfolgt wird. Also der macht mir dann auch quasi so einen continuous integration skip, immer wenn man da etwas eingibt. Wenn man diese Übergabe hat, hatten wir auch das Problem, wenn diese zehn Minuten exakt um sind, kann es passieren, dass man nicht mehr kompilierfähigen Code hat. Aber man checkt ihn trotzdem ein in diesen Branch, weil man eben sagt, jetzt wird übergeben. Das wird quasi durch diesen Branch und diesen continuous integration skip übergangen, sozusagen. Und dieses Tool hat eben Simon damals in seiner Freizeit noch ein bisschen geschrieben, dass man quasi mob start und mob next machen kann. Also wenn man weitergeben möchte, macht man mob next. Und der nächste, der anfängt, macht eben mob start und wenn man am Ende des Tages ist, macht man mob done oder wenn man, sage ich mal, eine Aufgabe abgeschlossen hat, dann macht man mob done, committet das Ganze in den Master hinein und gut ist es.

Simon Harrer: Und das ist halt wichtig, also man möchte diesen Handover wirklich möglichst zügig machen und da nicht so viel Zeit verlieren. Und da haben wir halt versucht, mit Tool-Support zu arbeiten, mit diesem Mob-Tool. Und wir arbeiten eben mit appear.in und da versuchen wir dann auch schnell eben diesem Screensharing-Wechsel auch noch hinzubekommen, aber das ist leider nicht so leicht zu automatisieren.

Stefan Tilkov: Da fehlt noch eine API bei appear.in, wo ihr das gleich mit ansteuern könntet, okay.

Simon Harrer: Exakt.

Stefan Tilkov: Das heißt aber auch, dass ihr, anders als bei anderen solchen kollaborativen remote-Ansätzen, nicht die gleichen Werkzeuge benutzen müsst. Ihr habt zwar zufällig die gleiche IDE, aber theoretisch könnte der eine von euch Emacs, der nächste VI und der dritte IntelliJ IDEA benutzen, das wäre dann eure Entscheidung?

Martin Huber: Das könnte man, aber dann würde quasi in einem gewissen Maßes der Lerneffekt verloren gehen. Also was ich jetzt zum Beispiel viel gelernt habe, sind auch Tastenkürzel oder Abkürzung in Richtung, wie kann ich was refactorn? Wie kann ich das durch ein Tastenkürzel ansteuern oder überhaupt Arbeitstechniken, die die Kollegen haben. Die habe ich mir auch mit aneignen können, und man gewinnt dadurch eine wahnsinnige Geschwindigkeit, weil man, sage ich mal, das Wissen von drei Leuten oder vier Leuten zusammenträgt. Jeder hat mal ein bisschen was herausgefunden, was der andere noch nicht kannte, das haben wir so halt auf die Art und Weise gelernt und sind auf die Art und Weise auch relativ schnell geworden.

Stefan Tilkov: Okay.

Martin Huber: Genau. Und das ist das, was dann der Vorteil ist, wenn man zufällig das gleiche Tool verwendet, dann kann man diesen Teil dann mitlernen, sozusagen.

Stefan Tilkov: Okay, verstehe ich. Das ist wahrscheinlich bei euch leichter durchzusetzen als bei den Emacs- und VI-Usern.

Martin Huber: Vermutlich ja. Wir sind aber auch relativ – wie soll ich sagen?

Simon Harrer: Wir haben jetzt alle auch das gleiche Setup, das macht es doch auch echt einfach. Wir haben alle das gleiche Betriebssystem und alle die gleiche IDE und dadurch können wir halt auch wirklich sehr gut dann das Wissen sharen.

Stefan Tilkov: Dann ist der Vorteil, den ich mir da einreden möchte, vielleicht von euch gar nicht so wahrgenommen worden. Also mich hätte das immer enorm genervt – Bei mir ist das zum Beispiel so: Ich habe eine Tastaturbelegung, bei der keine einzige Taste mehr das bedeutet, was darauf steht und ich kann auf nichts anderem tippen. Also ich könnte unmöglich am Rechner einer anderen Personen arbeiten. Es könnte jetzt irgendetwas sein, jemand könnte spezifische Tastenbelegung haben oder irgendwelche schrägen Tools oder einen komischen Editor, eine komische IDE. Das würde theoretisch alles unterstützt, aber das ist bei euch jetzt nicht der Faktor, der das treibt?

Martin Huber: Aber in deinem Fall wäre das sozusagen, du könntest weiterleben oder weiterarbeiten, aber wir könnten dir dabei halt nicht helfen, sagen wir es mal so. Du müsstest du dann halt einfach deine Geschwindigkeiten selbst [16:37 wählen/regeln].

Stefan Tilkov: Ja, das ist ja normal. Okay, gut, also ihr macht diese Übergabe, ihr arbeitet daran, ihr arbeitet auch im Prinzip den ganzen Tag daran. Jetzt ist ja die die Frage, die man beim Pair-Programming immer gerne stellt und die man bei euch dann natürlich noch mindestens anderthalbmal oder zweimal so dringend stellen müsste: Wie kann das denn um Himmels Willen wirtschaftlich sein, denn ihr arbeitet ja jetzt faktisch die ganze Zeit nur an einem Rechner und ihr seid zu dritt und jetzt sogar zu viert? Wie kann man das ökonomisch und kaufmännisch begründen?

Jochen Christ: Die Frage haben wir uns auch gestellt. Eine Antwort ist: Es funktioniert. Also empirisch funktioniert das bei uns ziemlich gut.

Stefan Tilkov: Es funktioniert in welcher Beziehung? Ihr seid dreimal oer mehr als dreimal so produktiv wie eine einzelne Person oder genauso produktiv, wie ihr zu dritt einzeln jeweils wärt?

Jochen Christ: Erst einmal halten wir unsere Zusagen, die wir jemand anderem geben, zum Beispiel an den Product-Owner, bisher immer ein.

Stefan Tilkov: Das muss man auch mal sagen, wir haben einen Kunden, der das mitmachen. Das muss man dem Kunden überaus hoch anrechnen. Das ist ja kein Geheimnis, sondern der Kunde weiß das und trägt das ja mit. Das ist ja schon mal toll, da kann man den Kunden nur loben.

Jochen Christ: Genau, also insofern, das, was wir dem Kunden versprechen, können wir bisher einhalten, in dem letzten halben, dreiviertel Jahr.

Stefan Tilkov: Und ihr seid nicht das einzige Team, es gibt ganz viele andere Teams, die gleichzeitig an diesem Projekt arbeiten. Das ist kein kleines Projekt insgesamt, also der Kunde kann auch beurteilen, dass das nicht irgendwie hinten rausfällt.

Jochen Christ: Genau und die Frage ist jetzt, woran liegt das eigentlich? Eine Haupterkenntnis, die wir sehen, ist, dass wir keine Warteabhängigkeiten haben. Bei einem klassischen Coding-Vorgehen ist es ja so, einer entwickelt irgendetwas und dann gilt das Vier-Augen-Prinzip, das heißt das, was entwickelt wurde, typischerweise auf einem Feature-Branch, muss über einen Code-Review gehen, dann über einen Merge-Request in den Master zurückgemerged werden. Das führt halt ganz häufig zu einem Kontextwechsel, der mental super teuer ist. Aber eben noch wichtiger ist, dass ich warten muss, bis jemand anderes sich dem annimmt und den Code-Review durchführt. Und dann gibt es vielleicht noch hin und her, gibt es noch Fragen, die man dann auch wieder asynchron beantworten muss, bis ich irgendwann in der Lage bin, das, was ich programmiert habe, in den Master zu mergen. Und dazwischen sind ganz viele Kontextwechsel und das haben wir halt gar nicht.

Stefan Tilkov: Und trotzdem ist euer Code reviewt.

Jochen Christ: Unser Code ist reviewt und zwar mit einem Sechs-Augen-Prinzip, mindestens. Also ich empfinde die Code-Qualität als sehr gut, weil hier immer sechs Augen draufschauen und einer ist eh immer da, der sagt, wir fangen jetzt mal mit dem Test an, und wir benutzen jetzt keine Abkürzungen. Auch da ist die gegenseitige Kontrolle einfach schon während des Schreibens, also kontinuierlicher Code-Review.

Stefan Tilkov: Habt ihr das Gefühl, dass sich das auch in der Fehlerrate niederschlägt? Also habt ihr das Gefühl, dass der Code weniger Fehler hat und weniger häufig angefasst werden muss als Code, den ihr sonst so kennt?

Martin Huber: Definitiv. Das würde ich sagen. Ich habe das Gefühl, dass wir schon relativ stabile Software haben. Das war auch im Prinzip, als wir angefangen haben, so unser oberstes Architekturziel, wenn wir so wollen: Wir wollen nicht nachts angerufen werden. Weil wir so ein System bauen, das sehr zentral, eine Datendrehscheibe zwischen vielen verschiedenen Systemen ist. Wenn man mit allen redet, hat man natürlich auch das Problem, dass man für alle verantwortlich ist und allen Antwort stehen muss.

Stefan Tilkov: Immer an allem Schuld ist.

Martin Huber: Genau, immer an allem Schuld ist. Und wir wollten vermeiden, dafür nachts rausgerufen zu werden. Dass wir eine stabile Software bauen, das war so unsere oberste Maxime. Und das ist auch immer noch das, was eben noch in unserem Kopf hinten schwebt, und dabei haben wir eigentlich alle drei, glaube ich, ein sehr gutes Gefühl, dass es das wirklich tut. Was ich jetzt aber da noch an der Stelle anmerken wollte. Was natürlich auch schon sehr zu Produktivität beiträgt, ist einfach dieser – wir nennen es Peer-Preasure, dass wir halt tatsächlich da sind, wir schauen uns an, wir sehen uns, wir sehen auch, wenn jemand abgelenkt ist. Das mag sich jetzt vielleicht ein bisschen stasimäßig anhören, das hat sich auch am Anfang ziemlich komisch angefühlt, muss man ganz ehrlich sagen. Man gewöhnt sich daran, es hat aber den Vorteil, dass man halt auch wirklich bei der Sache bleiben. Und die fünf, sechs Stunden, die man tatsächlich effektiv am Tag arbeitet, wenn man es mal ehrlich betrachtet… Wenn man jetzt normal für sich arbeitet, dann ist man halt auch hin und wieder abgelenkt, die Frau schreibt mal eine Whatsapp oder so etwas, dann antwortet man auch mal. Solche Sachen werden wirklich minimiert, also wirklich fast herausgenommen und das ist etwas, man ist einfach effektiv und produktiv bei der Sache. Das spiegelt sich auch im Code, im Produkt wieder, das muss man sagen. Es ist natürlich anstrengend, aber es ist okay.

Stefan Tilkov: Du hast gerade das Architektur-Thema erwähnt, wie spielt das dann da hinein. Also wie diskutiert ihr über die Vorgehensweise und wie trefft ihr Architektur-Entscheidungen? Ist das etwas, was ihr kollaborativ macht? Oder habt ihr das Gefühl, dass ihr das weniger tun müsst in der Abstimmung oder wie muss ich mir das vorstellen?

Simon Harrer: Das ist eine super Frage. Diese Architektur-Entscheidungen oder allgemein Entscheidungen treffen wir halt zu dritt. Da wechseln wir dann aus dieser Typist-Rolle heraus, wenn es sehr wichtige Entscheidungen werden, weil wir dann sagen, da wollen wir alle drei oder jetzt vier diskutieren. Und da versuchen wir so eine Art Prinzip für „Strong Opinions Loosely Held“, so nennt man das. Also man hat starke Gegensätze und man will möglichst viele Punkte auch abdecken, und eine sehr, sehr wohl fundierte Entscheidung treffen. Und diese Entscheidungen, die halten wir dann auch immer gleich fest als architecture decision records im Wiki und dokumentieren die dann eben auch für andere zum Nachlesen.

Martin Huber: Das Lustige ist, dass wir eben nicht nur Code zusammen schreiben, sondern solche Dokumentationen mittlerweile auch gemeinsam machen. Das geht dann auch gefühlt tatsächlich dreimal so schnell, als wenn man es alleine machen würde, komischerweise.

Stefan Tilkov: Vielleicht, weil man nicht das Motivationsproblem hat, dass man vor so einem leeren Bildschirm sitzt und erst mal starten muss, sondern irgendwer sagt dann schon wahrscheinlich etwas. Das kann ich mir gut vorstellen.

Jochen Christ: Auch hier hat man sofort eine Entscheidung. Man muss nicht zwei Wochen warten, bis das nächste Meeting stattfindet, [23:02 das nächste …]. Man kann einfach zusammen Entscheidungen fällen.

Stefan Tilkov: Okay, eure Meetings gibt es ja eigentlich nicht, beziehungsweise es gibt sie nur. Je nachdem, wie man es definieren will, korrekt?

Jochen Christ: Ja, genau. Also wir haben zum Beispiel kein klassisches Scrum-Daily oder Stand-Up, wir sehen uns eh die ganze Zeit und wissen, was wir tun. Wir versuchen, alle internen Meetings zu minimieren, die externen Meetings möglichst asynchron durchzuführen. Also wir informieren andere Teams über Check-Ins, zum Beispiel, über eine Nachricht im Chat, in dem alle anderen Teams auch mitlesen können, was wir gerade so machen. Daneben haben wir noch einen internen Blog, in dem wir in der Regel einmal pro Sprint aktuelle Themen ansprechen, die uns gerade bewegt haben. Aber auch hier eine sehr asynchrone Kommunikationsform zu externen Teams. Und dann, wenn ein konkreter Bedarf da ist, irgendetwas zu klären, irgendeine Schnittstellen-Abstimmung zu machen, dann gehen wir auf die anderen Teams zu und machen gemeinsam einen Termin, an dem wir das dann besprechen. Typischerweise aber auch einfach remote.

Stefan Tilkov: Okay. Du hast gerade schon Sprints und Scrum erwähnt. Dann ist klar, was ihr für eine Methodik in dem Projekt verwendet. Die Zusammenarbeit mit dem Product-Owner oder der Product-Ownerin passiert dann auch remote oder seid ihr da – ihr nickt, also auch remote. Und das heißt, ihr macht dann einfach gemeinsam – eigentlich ist das logisch, dass ihr gemeinsam die Schätzungen macht und ihr seid euch dann wahrscheinlich relativ schnell einig, weil ihr ja ungefähr wisst, wie ihr das tut. Okay.

Martin Huber: Ja, wir halten einfach die Finger in die Kameras, sozusagen, wenn wir Schätzungen machen.

Simon Harrer: Das ist übrigens sehr witzig, wie bei Schnickschnackschuck, wo man dann erst die Faust hat und dann… Genau.

Stefan Tilkov: Verstehe.

Jochen Christ: Also Planning-Poker vom Verfahren her. Ein jeder schätzt für sich und hält dann einfach die Anzahl der Story Points in die Kamera. Und das ist erstaunlich häufig, dass [24:59 sie allein da sitzt], also dass jeder das Gleiche hochhält.

Stefan Tilkov: Das hätte mich jetzt auch sehr gewundert, wenn das nicht so gewesen wäre. Ihr seid ja eigentlich nur ein Programmierer, sozusagen. Okay.

Martin Huber: Aber das Lustige an der Geschichte ist, weil du jetzt den Kontakt mit dem Product-Owner nennst oder auch zum Beispiel mit dem Enterprise-Architekten: Die wissen ja, dass wir quasi auch in den Kanal dann da herumfliegen, die kommen dann einfach mal herein, wenn sie eine Frage haben, dann kommen sie mal vorbei. Ich meine, das stört natürlich dann schon ein bisschen, aber das ist dann aber auch witzig, weil sie eben wissen, dass wir da sind. Und dann kommen sie herein, stellen ihre Frage und wenn sie die beantwortet bekommen haben, gehen sie wieder. Wir sind sozusagen irgendwie auch dort präsent über diesen remote-Kanal.

Stefan Tilkov: Okay, witzig. Wir haben das vorhin schon mal kurz angerissen: Ihr habt jetzt eine Kollegin und Person Nummer vier in dem in dem remote-Mob. Wie macht er das da? Ist die vierte Person einfach ein viertes Mitglied, gleicher Modus wie vorher? Habt ihr irgendetwas geändert im Ganzen?

Simon Harrer: Eigentlich haben wir nicht wirklich etwas geändert. Das ist Franziska Dessart, sie ist jetzt eben auch mit dabei und wir sind halt jetzt zu viert. Das heißt wir, wir kommen jetzt nicht mehr so oft als Typist dran, wenn wir durchrotieren, weil es ja jetzt vier Leute sind. Aber was aufgefallen ist, dass das Onboarding unglaublich gut funktioniert. Wir machen einen extremen Wissenstransfer. Ich glaube, es ist am Anfang auch sehr anstrengend für Franzi gewesen, aber ich glaube, sie ist sehr, sehr schnell hineingekommen. Und sie ist jetzt eigentlich seit wenigen Wochen ein vollwertiges Mitglied und ist genauso produktiv und hilft auch, dass wir insgesamt eigentlich noch schneller sind, weil sie ihren Wissensschatz oder ihr Wissen auch noch mit hineinbringt.

Stefan Tilkov: Und könntet ihr das bemessen? Also das ist jetzt auch wieder eine kaufmännische Frage. Das ist eine weitere Person mit dazu, das ist jetzt, glaube ich, nicht Vollzeit, aber ein geschätztes Drittel oder so oder von mir aus ein Viertel an Aufwand und Kosten noch einmal oben drauf. Habt ihr das Gefühl, das steht in einer guten Relation zu dem Mehrwert, den ihr dadurch habt? Ich versuche herauszufinden, was ist eine gute Größe, wann würde das gehen: Wenn es drei, fünf, vier sind, was ist die ideale Größe?

Jochen Christ: Ein Team von Vier hat halt den Vorteil, wenn einer mal im Urlaub ist, einer mal krank ist, dass der Rest immer noch Mob ist. Drei Leute bilden immer noch einen Mob und das ist der große Vorteil im Vergleich zu vorher. Wenn wir dann nämlich nur zu zweit waren zum Beispiel, ist man im Parry-Modus unterwegs. Und der hat wieder ganz andere Dynamiken, der funktioniert wieder anders. Und so haben wir eben als Viererteam den Vorteil, dass wir häufiger oder öfters im Mob einfach weiter arbeiten können.

Stefan Tilkov: Das heißt jetzt, das Idealmodell wäre, dass man immer mindestens drei hat und dann eben so viele Leute mit dazu hat, dass das immer gewährleistet ist. Das könnte man vielleicht so sagen? Ist das die richtige Formel dafür?

Jochen Christ: Also ich würde das relativ hart formulieren, dass die Obergrenze vier Personen sind für das Team. Bei mehr wird es dann, glaube ich, unwirtschaftlich irgendwann. Aber drei bis vier ist aus unserer Sicht so der Sweet-Spot, an dem sich das auf jeden Fall lohnt.

Martin Huber: Wenn denn nicht nur sogar unwirtschaftlich, sondern auch wirklich schwierig. Denn zu fünft remote ist dann schon wirklich noch mal [27:57 eine ganz andere Ausnahme/ ein ganz anderes Ausmaß]. Es ist ja schon schwierig, wenn man so ein sechs, sieben, acht, neun, zehn, zwölf Personen-Meeting hat, was wir ja auch öfters mal haben. Wenn so viele Leute dann aus verschiedenen Teams da zusammenkommen, das ist dann ja doch auch anstrengend, wenn man zwölf verschiedene Gesichter sieht und so weiter und jetzt dann noch zusammen programmieren… Das haben wir jetzt auch festgestellt. Also ich glaube, mehr als vier wäre wahrscheinlich wirklich schwierig.

Stefan Tilkov: Okay.

Simon Harrer: Aber das „anstrengend“ würde ich gerne noch mal aufgreifen, weil ich das total wichtig finde. Wir haben uns alle sehr professionelle Mikrofone gekauft, weil wir gemerkt haben, wenn wir den ganzen Tag miteinander kommunizieren und es gibt irgendwie schlechte Audioqualität, das ist super anstrengend für uns. Und das war eine sehr, sehr gute Entscheidung, das waren sehr gut investierte – ich glaube – hundert Euro oder so pro Person.

Jochen Christ: Richtig gut ist, dass wir nicht mehr mit der Headset da sitzen, sondern einfach vor dem Rechner sitzen und trotzdem eine perfekte Audioqualität haben. Das ist echt angenehm. Das ist sogar angenehmer als im Großraumbüro, in dem ich ja immer irgendeine Geräuschkulisse habe. Und im Großraumbüro denkt man ja eigentlich, dass die Kommunikation besser ist oder gut funktioniert –

Stefan Tilkov: Gibt es wirklich Leute, die das noch denken, mich würde das fast wundern. Ich vermute, die haben dann noch nie im Großraumbüro gearbeitet.

Jochen Christ: Ja, es werden aber immer noch welche gebaut. Also ich verstehe es auch nicht. Aber die Kommunikation über das Videokonferenz-Tool funktioniert einfach super. Man ist halt auch in so einem geschützten Raum unterwegs. Man kann auch heikle Dinge besprechen, weil keiner um einen herum ist, der irgendwie mithört, sondern man ist unter sich.

Stefan Tilkov: Okay, gut, was mich wahnsinnig interessieren würde: Ihr habt es zwar schon alle ein bisschen in euren Aussagen durchklingen lassen, aber ich hätte gerne noch mal so ein zusammenfassendes Statement von euch: Taugt das denn, also ist das gut? Simon, du hast es gerade schon direkt am Anfang gesagt: Du willst nicht mehr anders arbeiten. Warum? Was ist daran so gut?

Simon Harrer: Ganz, ganz viele Gründe. Einer, der jetzt auch noch ausschlaggebend für mich ist: Ich habe eine kleine Tochter. Ich wohne relativ abseits, aber ich möchte spannende Projekte machen, mit tollen Leuten und das ermöglicht mir das. Ich kann also zu Hause sein, ich bin aber nicht alleine. Sondern ich fühle mich in diesem Raum, als wäre ich mit den Kollegen und Kolleginnen einfach in einem an einem Büro, wo ich hinfahre, nur dass ich das von zu Hause aus machen kann und abends dann mit meiner Tochter und meiner Frau Abendessen kann, um achtzehn Uhr.

Stefan Tilkov: Großartiges Argument. Habt ihr noch mehr? Martin?

Martin Huber: Aber man muss ja sagen, das ist das Gute an dem Team, dass wir da wirklich auch offen ansprechen, wenn es einem mal zu viel geworden ist. Es gab so Momente, in denen es dem ein oder anderen tatsächlich mal zu viel geworden ist. Wo wir eben festgestellt haben, wir brauchen doch mal eine Pause zwischendurch oder auch vielleicht tatsächlich mal einen Nachmittag einfach mal etwas anderes tun. Oder sich mit irgendeinem Ticket tatsächlich mal zurückziehen und für sich sein. Das muss man schon irgendwie auch einplanen, finde ich. Also wenn ich sage, jetzt nur noch rund um die Uhr so arbeiten, das würde ich ehrlich gesagt nicht unterstützen, ich will ganz ehrlich sein. Aber ansonsten, muss ich gestehen, finde ich die Art der Arbeitsweise wirklich sehr gut. Und dieses Ergebnis, das man dabei erzeugt, ist wirklich phänomenal. Das habe ich mir am Anfang auch nicht so gedacht. Wie soll denn das funktionieren? Drei Leute machen ein Ticket? Aber die Fakten haben mich auch total überzeugt, dass das wirklich super ist. Und das macht dann auch richtig Spaß, wenn man richtig zusammen arbeitetet und in diesen Flow kommt, das ist wirklich eine gute Sache. Aber man darf das nicht unterschätzen, es ist auch eine anstrengende Sache. Man muss sich seine Pausen nehmen dürfen.

Stefan Tilkov: Okay. Jochen?

Jochen Christ: Genau. Was für mich persönlich ein mega Gewinn ist, ist, dass ich keine Zeit mehr im Auto oder in der Bahn verbringe oder die Zeit minimieren kann. Ich hab jeden Tag gefühlt zwei Stunden mehr Zeit, die ich dann halt entweder für den Kunden oder noch lieber mit meiner Familie verbringen kann. Und dabei verbrauche ich dann auch kein CO2, sondern ich bin halt daheim und ich laufe die Treppe hoch und bin an meinem Computer. Und das fühlt sich irgendwie gut an.

Stefan Tilkov: Okay, sehr cool. Ihr habt das Ganze verschriftlicht, ihr habt eine sehr coole Website gebaut, dazu remotemobprogramming.org heißt sie. Darauf stehen noch ein paar andere Dinge, wir können mal kurz darauf schauen. Das sind, glaube ich, fünfzehn Punkte, die ihr aufgeschrieben habt. Ich glaube, die meisten davon haben wir angesprochen. Haben wir etwas vergessen, lasst uns kurz mal schauen.

Simon Harrer: Vielleicht „same time“, wir arbeiten ja synchron, wir arbeiten gleichzeitig zusammen. Das hat dazu geführt, dass wir uns für die Mittagspause immer koordinieren, denn wenn wir die Mittagspause verschieben würden, würden wir sehr viel Zeit, wertvolle Zeit, in der wir alle drei oder jetzt vier zusammen sind, verlieren und das koordinieren wir. Und das ist erst einmal komisch, weil im remote-Setting, [33:08 macht es ja nicht jeder selber] und geht dann halt Mittagessen, wann er das möchte. Und es ist praktisch wie im echten Office: Man koordiniert das und geht dann gemeinsam Mittagessen, aber eben separat.

Martin Huber: Und ein Punkt, den wir auch noch nicht haben, ist, dass wir uns tatsächlich aber auch regelmäßig mal treffen in einem Office. Also in einem offenen Open Office in Nürnberg zum Beispiel haben wir uns schon mehrfach getroffen um mal so Sachen auszumachen. Wir haben uns aber auch schon privat getroffen, wir waren schon zweimal bei Jochen, einmal dann sogar mit anschließendem Grillen. Er hat uns dann dazu eingeladen, das war total super. Man kann das ja dann auch verbinden mit Socialisingaspekten, wenn man das jetzt hier in dem Zusammenhang so formulieren kann. Insofern ist das wirklich super, man muss sich auch ab und zu treffen, man muss auch ab und zu mal gemeinsam vor einem Flipchart stehen, das muss man mal sagen.

Stefan Tilkov: Okay, gut. Wir haben ganz viele Shownotes; wir werden das Buch verlinken, das am Anfang erwähnt wurde, den ein oder anderen Talk. Wir werden natürlich die Website verlinken, auf der das draufsteht. Es gibt, glaube ich, mittlerweile schon irgendwo einen Artikel und ein Interview. Wir machen also ein paar Shownote-Links und ich bin sicher, ihr freut euch über Feedback von interessierten Entwicklern, Entwicklerinnen, die das auch mal ausprobieren wollen. Denn ich glaube, ihr seid alle ziemlich begeistert und mich zumindest habt ihr angesteckt? Das ist wirklich cool. Wunderbar, haben wir noch etwas vergessen, wollte ihr noch etwas hinzufügen oder haben wir alles?

Martin Huber: Nein, erst mal nicht.

Stefan Tilkov: Alles klar. Vielen Dank für eure Zeit und danke an die Zuhörer fürs Zuhören.

Martin Huber: Danke für deine Zeit.

Jochen Christ, Simon Harrer, Martin Huber: Ja, danke. Tschüss.