Cloud-Native

Data & KI

Produktentwicklung

Resilienz & IT-Security

Leistungen

Arbeitsweise

Projekte

Berlin

Bielefeld

Dortmund

Erfurt

Frankfurt am Main

Hamburg

Karlsruhe

Leipzig

München

Münster

Nürnberg

Solingen

Stuttgart

Standorte

Blog

Softwerker

Fachmedien

Webinare

Events

Wissens-Hub

Unsere Kultur

Deine Entwicklung

Jobs

Karriere

Über uns

Aktuelles

Kontakt

International contact

Alle Standorte

Du hast Fragen oder möchtest dich mit mir austauschen? Gern - trag einfach deine Kontaktdaten ein.

Kontakt aufnehmen

Marketing & Community Management

Konntest du keine Einträge zu deinem Thema finden?  

Software Team Enabler

CloudLand 2023

Agile Transformation

Kultur

Guerilla Organisation Enablement - Developer-driven Transformation

TOD (Team-oriented development/Teamorientierte Entwicklung) ist ein Begriff, den wir geprägt haben, um einen flexiblen Entwicklungsalltag zu beschreiben. Nachdem wir in unserem letzten Team mit den verschiedensten Programmier-Modi experimentiert hatten, fanden wir es unnötig, Ansätze wie „Pair Programming“, „Ensemble Programming (früher Mob Programming)“, „Parallel Programming“ und „Einzelkämpfer-Modi“ voneinander abzutrennen. Im Laufe des Tages sprangen wir zwischen diesen Techniken hin und her, wobei ständig neue Variationen entstanden, je nachdem, wie es die Situation erforderte. TOD beschreibt diesen flexiblen Ansatz des ständigen Experimentierens, bei dem wir nicht an künstliche Leitplanken gebunden waren, sondern uns als Gruppe weiterentwickeln konnten, mit dem Vorteil, einen Shared-Everything-Ansatz im Team zu etablieren. Die Konzentration auf Programmiertechniken, an denen zwei oder mehr Personen beteiligt sind, hat uns also geholfen, unser Wissen auf intelligente Weise an das gesamte Team weiterzugeben. Und das Ganze machte obendrein noch jede Menge Spaß.TOD ist für uns eines der besten Werkzeuge, um Wissen im Team zu teilen, die Entwickler-Skills zu verbessern und den Zusammenhalt und Spaß im Team zu erhöhen. In diesem Artikel geben wir euch einen Überblick über die Techniken innerhalb von TOD und teilen unsere Erfahrungen, die wir in realen Projekten mit TOD gemacht haben.<h2>Pair Programming – ein guter Einstieg</h2><a href="https://media.graphassets.com/dCcEXE76Sry07IprBnFM"><img src="https://media.graphassets.com/dCcEXE76Sry07IprBnFM" alt="pair programming" width="1024" height="607" /></a> Die Konzentration auf Programmiertechniken, an denen zwei oder mehr Personen beteiligt sind, hat uns geholfen, unser Wissen auf intelligente Weise an das gesamte Team weiterzugeben. Eine Methode, die auch Spaß macht.Pair Programming ist eine gute Möglichkeit, mit dem Wissensaustausch zu beginnen. Zwei Programmierer lösen gemeinsam ein Problem, sprechen darüber, tauschen Ideen aus usw. Es ist auch gut, um jemanden nach Urlaub oder Krankheit auf den neuesten Stand zu bringen, ohne den Rest des Teams auszubremsen.Verschiedene Studien (z. B. [1] und [2]) berichten über eine bessere Code-Qualität während der Software-Entwicklung mit dem Resultat, dass am Ende weniger Bugs entstehen. Sobald man anfängt, die Einzelkämpfer-Rolle aufzugeben, wird man definitiv bessere Ergebnisse erzielen. Ein positiver Nebeneffekt ist, dass man beginnt, den Bus Factor und das Wir-Gefühl innerhalb des Teams zu erhöhen.Ein Nachteil beim Pair Programming verbirgt sich im Wort „Pair“: Bei dieser Methode sind nur zwei Programmierer beteiligt. Sie kann dazu führen, dass einzelne Teammitglieder kleine Teile des gesamten Wissens verlieren, was nicht gut für die Verbreitung von Wissen im Team wäre. Das war ein Grund, warum wir versucht haben den Einsatz von Pair Programming auf das nötige Minimum herunterzufahren.<h2>Ensemble Programming – erhöhe den Bus Factor des Teams</h2><a href="https://media.graphassets.com/nQlX4jEsQK6NCtabk45Q"><img loading="lazy" src="https://media.graphassets.com/nQlX4jEsQK6NCtabk45Q" alt="mob-soft-mode" width="1024" height="511" /></a> Ensemble Programming (früher Mob Programming) macht Spaß und ist eine gute Möglichkeit, Wissen im ganzen Team zu verbreiten. Ensemble Programming bedeutet, dass ein Team von Entwicklern (4-6 Personen sind perfekt) einen Computer benutzt, um an einer Aufgabe zu arbeiten. Einer der Gruppe ist das „intelligente Eingabegerät“, während die anderen dafür verantwortlich sind die Person an der Tastatur zu navigieren.<a href="https://media.graphassets.com/pmb5PQinRL6YYjgW2IIg"><img loading="lazy" src="https://media.graphassets.com/pmb5PQinRL6YYjgW2IIg" alt="mob programming-in-a-nutshell" width="1024" height="867" /></a> Die Rolle des Drivers wechselt häufig, zum Beispiel alle 7 Minuten. Hier solltet ihr mit eurem Team experimentieren, um den für euch besten Timer zu finden. Ihr solltet auch verschiedene Driver-Navigator-Patterns ausprobieren. Dies alles wird euch helfen, das Wissen im gesamten Team zu verbreiten. Außerdem wird es sich positiv auf den Bus Factor eures Teams auswirken. Der Bus Factor definiert den Gesundheitszustand eures Teams. Wenn sich der Bus Factor eurer Teamgröße nähert, bedeutet das, dass das Team gesund bleibt, auch wenn einige Teammitglieder ausfallen. Kurz gesagt, der Bus Factor bedeutet, dass, wenn eine Person des Teams von einem Bus überrollt wird, das Team in Schwierigkeiten geraten würde, wenn diese Person über ein spezielles Wissen verfügt und die einzige Person wäre, die dieses Wissen besitzt.Ein effektives Ensemble Programming erfordert Fähigkeiten, die im Laufe der Zeit aufgebaut werden. Am ersten oder gar am zehnten Tag wird es nicht perfekt funktionieren. In einem früheren Blog-Beitrag haben wir die Einzelheiten von „Ensemble Programming und Share Everything“ bereits <a href="https://blog.codecentric.de/2020/03/mob-programming-shared-everything/">beschrieben</a> . Dort werdet ihr auch ausführlichere Informationen über die verschiedenen Muster und Experimente erhalten, mit Fokus auf Remote Ensemble Programming.<h2>Parallel Programming – Alle für einen</h2>Streng genommen erlauben Ensemble Programming und Pair Programming nur einen Bildschirm und eine Person, die gleichzeitig tippen kann. Jeder, der mit den Techniken gearbeitet hat, wird zustimmen, dass es Situationen gibt, in denen dies frustrierend und einschränkend sein kann. Es ist eine Kunst, lange genug dabei zu bleiben und sich von dieser Frustration zum Lernen zwingen zu lassen, und dennoch zu wissen, wann es wirklich an der Zeit ist, sich zu trennen und parallel zu arbeiten.<a href="https://media.graphassets.com/2ytsF8sJQVShhXRW7bw3"><img loading="lazy" src="https://media.graphassets.com/2ytsF8sJQVShhXRW7bw3" alt="parallel programming" width="1024" height="696" /></a> Als wir an den Punkt kamen, an dem es schwierig war, eine gute Lösung für ein Problem zu finden, und fast jeder in der Gruppe eine Idee hatte, um es zu lösen, haben wir Ensemble Programming gestoppt und, wie wir es nannten, „Parallel Programming“ gestartet. Jeder versuchte, das Problem auf seinem eigenen Rechner zu lösen, während man in der Videokonferenz online blieb oder man zusammensaß. Jeder durfte reden und konnte sich gegenseitig fragen oder über Erkenntnisse sprechen.Das traditionelle Ensemble Programming ist in dieser Situation frustrierend, weil eine Person die Dokumentation lesen will, eine andere versucht Code zu ändern oder einen Befehl auszuführen, und eine andere Person nach Antworten im Internet suchen möchte. Und das Lesen von Text auf dem Bildschirm eines anderen ist eine Herausforderung an sich, wenn z.B. unerwartetet gescrollt wird, usw.<a href="https://media.graphassets.com/0SMIWxylS1C2Kwmws2zN"><img loading="lazy" src="https://media.graphassets.com/0SMIWxylS1C2Kwmws2zN" alt="single piece flow" width="1024" height="672" /></a> Einer der Vorteile von Ensemble Programming ist der Single-Piece-Flow – die Idee, dass immer nur an einem Punkt gearbeitet wird. Eine schlanke Produktion wertet das Konzept zusätzlich auf. Das Gute bei Parallel Programming ist, dass es den Single-Piece-Flow behält. Alle Entwickler arbeiten immer noch an der gleichen Aufgabe. Aber das parallele Arbeiten gibt ihnen die Freiheit, die Richtung einzuschlagen, in die sie gehen wollen. Ein Beispiel dafür ist die Fehlerbehebung. Wenn der Fehler schließlich gefunden wird, erklärt die Person, die ihn gefunden hat, den anderen das Problem. Die anderen verstehen die Erklärung sofort, weil sie sich gerade mit derselben Sache innerhalb desselben Kontextes beschäftigt haben.Nützlich hierbei war für uns die Festlegung von Time-Boxen (etwa 20 Minuten). Nachdem die Zeit abgelaufen war, kamen wir wieder zusammen, um unsere individuellen Recherchen auszutauschen und zu entscheiden, ob wir mehr Zeit benötigen (eine weitere Zeitbox einzurichten) oder ob wir wieder mit Ensemble Programming weiter machen und eine der gefundenen Lösungen ausprobieren wollten. Während des Ensemble Programmings und des Experimentierens mit verschiedenen Modi fanden wir es auch vorteilhaft, Time-Boxen einzurichten, wodurch eine gewisse Disziplin entsteht.<h2>Anwendung der Techniken in der Praxis</h2>Bei einem unserer letzten Projekte haben wir mit Ensemble Programming begonnen. Nach einer Weile ließen wir uns von den Herausforderungen entmutigen und wechselten zu Pair Programming und Einzelkämpfer-Modi. Aber wir probierten den Ensemble-Ansatz immer mal wieder aus. Irgendwann hatten wir eine gewisse Sicherheit bei Ensemble Programming erreicht und, was wichtiger war, dessen Vorteile erkannt. Wir kamen zu der Einsicht, dass wir so viel wie möglich als Team zusammenarbeiten wollten und dass wir Ensemble Programming als unsere Haupttechnik zur Softwareentwicklung einsetzen wollten. Wir beschlossen Einzelkämpferaufgaben in unserem Tagesgeschäft so weit wie möglich zu reduzieren, was meist abhängig von der Arbeit bzw. Aufgabe war. Wenn es zur aktuellen Aufgabe passt, ist Einzelkämpferarbeit durchaus sinnvoll. Wir wollten sie einfach auf ein vernünftiges Minimum reduzieren.Ein Nachteil von striktem Pair oder Ensemble Programming ist, dass die Arbeitszeiten synchronisiert werden müssen. Dies ist mit gewissen sozialen Kosten verbunden. Wir hielten es für ein besseres Modell, alle arbeiten zu lassen, wann sie wollten, mit grober Orientierung an den üblichen Bürozeiten. Daran sind die meisten Programmierer bereits gewöhnt. Wenn jemand von Natur aus 30 Minuten früher als andere im Büro eintrifft, sollte er sich eine andere Aufgabe suchen, die sich am besten als Einzelkämpfer bewältigen lässt. Teams können solch relevante Aufgaben auf eine To-do-Liste (oder Single-Task-Backlog) setzen, um auf solche Momente vorbereitet zu sein. Wenn später weitere Entwickler zur Arbeit kommen, können sich daraus Pair- oder Ensemble-Programming oder mehrere Pair-Programming-Sessions, usw.,  entwickeln.<a href="https://media.graphassets.com/ktPI88BJSmC5Ogjl9LA6"><img loading="lazy" src="https://media.graphassets.com/ktPI88BJSmC5Ogjl9LA6" alt="distribution methods" width="1024" height="683" /></a> Wie im Diagramm grob dargestellt, haben wir als primäre Technik Ensemble Programming verwendet. Seit wir die großen Vorteile von Parallel Programming entdeckt haben, haben wir sie häufiger als Pair Programming zusammen mit Ensemble Programming eingesetzt. Aber wir entdeckten diese Technik erst in einem späteren Stadium des Projekts, was den kleineren Balken im Diagramm erklärt.<h2>Finde den Weg für dein Team</h2>Der oben beschriebene Team-Lernprozess nahm Zeit in Anspruch. Das Team muss erst seinen optimalen Weg finden – was eine gewisse Zeit beansprucht.Vielleicht wird euer Team feststellen, dass es am bequemsten und effizientesten ist, wenn es hauptsächlich mit Pair Programming arbeitet. Solange das Team zufrieden ist und seine Ziele erreicht, ist das in Ordnung. Darum geht es bei TOD wirklich: ein Team, das frei experimentiert und gemeinsam den besten Ansatz für sich entdeckt. Und doch bedeutet die Denkweise eine kontinuierliche Verbesserung, während das Team seinen idealen Ansatz sucht. Wir fordern uns selbst immer wieder heraus, sammeln Ideen und versuchen neue Experimente, um uns stetig weiter zu verbessern.TOD ist teamspezifisch. Euer Team könnte einen idealen Weg finden, aber wenn ihr als Einzelperson einem neuen Team beitretet, müsst ihr bereit sein, euch anzupassen, den Prozess neu zu beginnen und die in diesem Szenario gewonnenen Erkenntnisse und Ergebnisse akzeptieren.<h2>TOD stärkt dein Team</h2>Wir stellten bei der Einführung der teamorientierten Entwicklung fest, dass das Wir-Gefühl und die Wohlfühl-Atmosphäre von Tag zu Tag zunahmen. Wir wuchsen zu einem starken Team zusammen, in dem jedes einzelne Teammitglied hoch motiviert war und seine ganze Energie einsetzte. Wir erkannten auch, dass so etwas wie ein Wissens-Safe-Space entstand. Jeder hatte sein eigenes Fachwissen und konnte bei verschiedenen Dingen helfen. Und jeder war bereit zu lernen. Somit hatte niemand im Team Angst zu fragen: „Das habe ich nicht verstanden. Kann es mir nochmal jemand erklären?“.<a href="https://media.graphassets.com/D90bLA51SCGe9TfeDg4A"><img loading="lazy" src="https://media.graphassets.com/D90bLA51SCGe9TfeDg4A" alt="we are the team" width="1024" height="697" /></a> Klingt das alles gut für euch? Warum versucht ihr dann nicht heute euer erstes kleines Experiment? Macht die Teamarbeit wieder großartig und wertvoll!<h2>Quellen</h2>[1] Herez Moise Kattan, Flavio Soares, Alfredo Goldman, Eduardo Deboni, and Eduardo Guerra. 2018. Swarm or pair? strengths and weaknesses of pair programming and mob programming. In Proceedings of the 19th International Conference on Agile Software Development: Companion (XP ’18). Association for Computing Machinery, New York, NY, USA, Article 43, 1–4. DOI:<a href="https://doi.org/10.1145/3234152.3234169" target="_blank">https://doi.org/10.1145/3234152.3234169</a> [2] Jim Buchan and Mark Pearl. 2018. Leveraging the Mob Mentality: An Experience Report on Mob Programming. In Proceedings of the 22nd International Conference on Evaluation and Assessment in Software Engineering 2018 (EASE’18). Association for Computing Machinery, New York, NY, USA, 199–204. DOI:<a href="https://doi.org/10.1145/3210459.3210482" target="_blank">https://doi.org/10.1145/3210459.3210482</a>

Team-oriented development

Mob Programming ist eine Methode, die wir exzessiv eingesetzt haben, um den Wissensaustausch im Team zu fördern, Entwickler-Skills zu schärfen und den Teamzusammenhalt zu erhöhen. Das mögen nicht unbedingt die Primärziele eures Unternehmens sein, aber sie tragen enorm dazu bei, eure eigentlichen Ziele erfolgreich zu erreichen. In diesem Artikel teilen wir mit euch die Ansätze, die wir nutzten, um Mob Programming machbar, effektiv und unterhaltsam zu machen.<h2>„Shared Everything“</h2>In einem unserer letzten Projekte haben wir Mob Programming eingeführt, um das Hauptziel „Wissensaustausch im Team“ zu erreichen. Wir wollten damit alle Entwickler auf das gleiche Niveau bringen, statt uns mit Titeln, Kategorisierungen und Spezialisierungen aufzuhalten. Das Ergebnis unserer kontinuierlichen Arbeit an einem „Shared Everything“-Mindset war, dass unser „Bus Factor“ sich an unsere Teamgröße annäherte.<h2>Bus Factor?</h2>In jedem Team findet man einzelne Personen, die ein Silo an spezifischem Wissen darstellen. Wissen, das essentiell für die Ergebnisse und die Performance des Teams entscheidend ist. Wenn eine solche Person nun das Team plötzlich verlässt, wird das gesamte Team darunter leiden.<div><a href="https://media.graphassets.com/vcASUP2US3ypx1fWG0x6"><img src="https://media.graphassets.com/vcASUP2US3ypx1fWG0x6" alt="bus factor" width="1024" height="1024" /></a> Bild von Lai Man Nung, unsplash</div>Der Bus Factor eines Teams ist die Anzahl der Teammitglieder, die „von einem Bus überfahren werden müssen“, damit ein Team in ernste Schwierigkeiten kommt.Somit ist der Bus Factor ein Indikator dafür, wie „gesund“ dein Team in Bezug auf Wissenstransfer und Skill-Sharing ist. Ein hoher Bus Factor deutet auf einen guten Wissenstransfer innerhalb des Teams hin.Wie haben wir Mob Programming und Shared Everything etabliert?<h2>Mob Programming – Ein Abenteuer</h2><div><a href="https://media.graphassets.com/TcK4szlwRg2bBnWxfRXX"><img loading="lazy" src="https://media.graphassets.com/TcK4szlwRg2bBnWxfRXX" alt="remote mob session" width="1024" height="640" /></a> Remote Session – Bild von den Autoren</div>Während des besagten Projektes waren wir in der glücklichen Lage, DDD (Domain-driven Development), TDD (Test-driven Development), und, was wesentlicher war, Mob-Programming-Techniken zu verwenden.Wir hatten einen holprigen Start. Mob Programming fühlte sich für uns total fremd an gegenüber der Art der Softwareentwicklung, die wir gewohnt waren. In täglichen Retrospektiven wurde das Gefühl von Verlangsamung beanstandet und man war relativ schnell frustriert, dass man nicht mehr wie gewohnt die Macht über das Keyboard und die damit verbundene Kontrolle hatte. Wir versuchten es, gaben es auf, starteten neu und hörten wieder auf.Was wir damit sagen wollen, ist, dass wir am Anfang viel experimentierten. Während dieser Phase wurden wir durch den <a href="http://www.mobprogrammingguidebook.com/images/mobprogrammingguidebook.pdf" target="_blank">Guide von Maaret Pyhäjärvi</a> inspiriert.Wir begannen zu erkennen, dass Wissen im Team viel besser zu den einzelnen Teammitgliedern transferiert wurde und sich auch unsere Codequalität erhöhte.Dennoch blieben die Herausforderungen bestehen. Wir waren auch zu Beginn an einem Punkt angekommen, an dem wir diese eigentlich gute Idee aufgeben wollten. Aber wir hatten dann einen sehr guten Workshop mit <a href="https://woodyzuill.com/" target="_blank">Woody Zuill</a> . Dieser Workshop-Tag half uns enorm dabei, festzustellen, dass die Mob-Programming-Technik uns unterstützt, uns selbst als Menschen, aber auch als Team weiterzuentwickeln. Wir waren wieder enthusiastisch! Neben den vielen Tipps und Tricks, die Woody uns mitgab, war eines für uns entscheidend: die Daily Retrospektive. Eine tägliche Retro? Ja. Jeden Tag um ca. 16 h kamen wir für fünf Minuten zusammen. In dieser Retro geht es darum, dass jeder etwas sagt, was an diesem Tag gut gelaufen ist. Wir empfehlen euch, dafür einen Alarm einzurichten, um damit vertraut zu werden.Eine weitere Herausforderung bei uns war, dass wir den Fokus auf Remote Mob Programming setzen mussten, da ein Teil unseres Teams über verschiedene Standorte verteilt war. Hierbei holten wir uns Inspiration aus dem <a href="https://www.remotemobprogramming.org/" target="_blank">Guide von Simon Harrer, Jochen Christ, und Martin Huber</a> . Wir mussten einige Regeln etablieren, um Remote-Arbeit für uns erfolgreich zu machen.<h3>Einige „Shared Everything“-Regeln</h3><ul><li>Kamera immer an<div><a href="https://media.graphassets.com/VTdOSJtJQeiS1WqvFls9"><img loading="lazy" src="https://media.graphassets.com/VTdOSJtJQeiS1WqvFls9" alt="webcam" width="1024" height="387" /></a> Bild von Aksa2011, pixabay</div>Da das Team über verschiedene Standorte verteilt war, war es für uns besonders wichtig, die „Kamera immer an“-Regel zu forcieren. Das hilft allen Teammitgliedern, sich wie „Bürger erster Klasse“ zu fühlen. Es gibt, vor allem für die Remote-Mitglieder, ein besseres „Wir“-Gefühl. Zusätzlich hat es den Vorteil, dass bei Diskussionen und Meetings ein besseres Verständnis erzielt wird, weil man neben der Sprache so auch die Gestik der sprechenden Person mitbekommt. Das bringt uns zur nächsten Regel …</li><li>30-Sekunden-Regel<div><a href="https://media.graphassets.com/sVvcOf0SgiV23REl1cib"><img loading="lazy" src="https://media.graphassets.com/sVvcOf0SgiV23REl1cib" alt="timer" width="1024" height="358" /></a> Bild von Aron Visuals, unsplash</div>Wenn jemand mehr als 30 Sekunden spricht und sich dabei außerhalb der Kamera befindet, kann jeder das Meeting unterbrechen, damit die Situation bereinigt werden kann.Da bei uns im primären Projektbüro jeder sein eigenes Notebook verwendete, war es sowieso Standard, dass jeder die ganze Zeit vor der Kamera war.In den Business-Meetings mit unseren Stakeholdern war jeder angehalten teilzunehmen, damit wir unsere „Shared-Everything“-Philosophie forcieren konnten. Es war entscheidend, unsere Einrichtung so anzupassen, dass alle Gäste im Raum von den Remote-Mitgliedern/-Teilnehmern deutlich gesehen werden konnten – ob es darum ging, die Körpersprache wahrzunehmen oder einfach nur zu wissen, wer genau spricht. Daher machte diese Regel auch einen Unterschied wie Tag und Nacht. Die zusätzlichen Personen wurden also vor Beginn des Meetings auf die vorhandenen Kameras (Notebooks) verteilt. Die Beteiligten haben in unserem Fall sehr gut mitgespielt.</li><li>10-Minuten-Regel<div><a href="https://media.graphassets.com/oEQjn2jRbq6UtqaQlPLf"><img loading="lazy" src="https://media.graphassets.com/oEQjn2jRbq6UtqaQlPLf" alt="speaking" width="1024" height="355" /></a> Bild von Clem Onojeghuo, unsplash</div>Bei der 10-Minuten-Regel geht es im Wesentlichen darum, dass jeder Teilnehmer ausreichend abgeholt ist. Falls einer der Beteiligten für mehr als zehn Minuten nichts sagte, wurde das Meeting kurz unterbrochen und derjenige sollte kurz den Stand zusammenfassen. Das klingt nach einer harten Regel, ja, aber für uns war es extrem wichtig, dass jeder alles mitbekam. Nur so konnten wir einen guten Wissenstransfer sicherstellen. Üblicherweise ist es ein Indikator, falls jemand eine Weile nichts zu sagen hat, dass derjenige den Faden der Konversation verloren hat.</li><li>Brauchst du eine Pause? Nimm dir eine.<div><a href="https://blog.codecentric.de/files/2020/02/break_unsplash_alex-scaled.jpeg"><img loading="lazy" src="https://media.graphassets.com/hLRSuRTtSsyMGTgQQsIZ" alt="break" width="1024" height="368" /></a> Bild von Alex, unsplash</div>Mob Programming braucht eine extrem hohe Fokussierung und Aufmerksamkeit von jedem. Hinzu kommt, dass Lernen schnell müde macht. Somit war es jedem in unserem Team erlaubt, eine Pause zu machen, wann immer eine benötigt wurde. Das Positive bei Mob Programming ist, dass man sehr schnell wieder auf dem Laufenden ist, wenn man aus einer Pause zurückkehrt. Wir haben verschiedene Pausenmodelle ausprobiert und sind am Ende bei der individuellen Pause geblieben. Das Einzige, was wir versucht haben zu synchronisieren, war die Mittagspause. Ansonsten konnte sich jeder eine individuelle Pause nehmen, sofern es nötig war. Die Person wurde dann einfach immer an das Ende der Mob-Programming-Liste gefügt und konnte sich somit eine Runde lang aufgleisen.</li></ul>Bei Business-Meetings haben wir allerdings eine andere Pausenregelung angewandt. Wir haben hier die 45-Minuten-Regel verwendet. Also alle 45 Minuten eine kurze Pause. Das war besonders für unsere Remote-Teilnehmer sinnvoll, weil diese Meetings anstrengend sein können, wenn man nicht unbedingt in seiner Muttersprache folgen muss.Die Regeln oben halfen uns während der Mob-Programming-Sessions sehr. Und Mob Programming half uns, das gesamte Wissen an jedes einzelne Teammitglied weiterzugeben. Jeder in unserem Team kannte also jede kleine Ecke unserer Anwendung und konnte an jedem Teil davon arbeiten.<h2>Unsere Experimente</h2>Wie wir bereits erwähnten, haben wir viel experimentiert. Experimente machen Spaß. So haben wir zum Beispiel verschiedene Ansätze für Mob Programming, die wir in „Dojos“ bei Woody Zuills Workshop gelernt haben, ausprobiert. Wir haben sie strict, soft und freestyle genannt:<ul><li>Strict <a href="https://media.graphassets.com/Tt1WsMZmRXqkIkE4VKy0"><img loading="lazy" width="250" height="117" src="https://media.graphassets.com/Tt1WsMZmRXqkIkE4VKy0" alt="mob-strict-mode" /></a> Die strikte Art und Weise, Mob Programming durchzuführen, bedeutet, dass ausschließlich der Navigator reden darf. Der Rest darf nur zuschauen. Man darf nicht antworten, auch nicht auf direkt gestellte Fragen. Man kann sich vorstellen, dass das ziemlich schnell frustrierend sein kann. Vor allem, wenn man mit ansehen muss, wie der Navigator anfängt zu straucheln und einem nicht erlaubt ist, zu antworten oder Hinweise zu geben. Allerdings kann das überraschenderweise große Benefits mit sich bringen. Der Navigator zum Beispiel lernt laut zu denken, was wiederum der nächste Navigator aufgreifen kann. Dem Mob Fragen zu stellen ist eine effektive Methode der Kommunikation (auch wenn diese unbeantwortet bleiben)Auf der anderen Seite lernt der Mob, sich in Geduld zu üben und, was wir als wichtiger empfinden, dem Navigator Raum zu lassen, Dinge einfach auszuprobieren. Wenn man gelernt hat, mit diesen Frustrationen umzugehen, wird man merken, dass diese Art und Weise eine sehr friedvolle Technik ist. Keine Diskussionen, keine Argumente. Einfach programmieren und dabei versuchen, den anderen und dessen Gedankengang zu verstehen.</li><li>Soft <a href="https://media.graphassets.com/aLFbgfSTSeKvUiNeZHiY"><img loading="lazy" width="250" height="125" src="https://media.graphassets.com/aLFbgfSTSeKvUiNeZHiY" alt="mob-soft-mode" /></a> Diese Art ist ähnlich zur strikten Methode, mit dem Unterschied, dass der Mob reden darf, falls eine Frage vom Navigator gestellt wird. Man kann auf Fragen reagieren oder die Hand heben und warten, bis man an der Reihe ist, wenn man einen Hinweis oder eine Idee teilen möchte. Das erlaubt es, einem strauchelnden Teammitglied aktiv helfen zu können. Nichtsdestotrotz kann diese Technik in lange Diskussionen und den Freestyle-Modus abschweifen. Daher ist hier Vorsicht geboten.</li><li>Freestyle <a href="https://media.graphassets.com/EcCuXNZcSF2VpSwJA6Nk"><img loading="lazy" width="250" height="116" src="https://media.graphassets.com/EcCuXNZcSF2VpSwJA6Nk" alt="mob-freestyle-mode" /></a> Im Freestyle-Modus gibt es nur den Driver und alle anderen sind Navigatoren. Jeder darf frei Hinweise, Kommandos, Ideen äußern oder eine Diskussion starten. Wir haben gemerkt, dass es bei dieser Methode wichtig ist, Techniken anzuwenden, die Diskussionen reduzieren. Eine Möglichkeit ist es, die Idee eines Teammitglieds aufzugreifen und durchzuführen, egal ob sie gut oder schlecht endet, statt diese totzudiskutieren. Das Ergebnis kann überraschend sein!</li></ul>Wir waren die meiste Zeit im Soft-Modus unterwegs, ein guter Kompromiss zwischen den anderen beiden Modi. Auch haben wir während des Tages immer mal wieder den Freestyle-Modus angewandt. Zudem haben wir uns einen Timeslot pro Tag (maximal eine Stunde) für den strikten Modus genommen, weil wir das Training für Geduld und Lösungsfindung sehr gut fanden.Zudem haben wir viel mit der Mob-Programming-Rundenzeit experimentiert. Wir haben sehr kurze (2-3 min), mittlere (5-12 min) und lange (15-25 min) Rundenzeiten ausprobiert. Wir haben eine Zeit ausgewählt und 1-2 Runden Mob Programming durchgeführt. Wir haben festgestellt, dass bei den langen Zeiten sehr schnell der Fokus verloren wurde. Auch bei den zu kurzen Zeiten waren wir uns schnell einig, dass es nicht funktioniert, weil einfach zu wenig Zeit war, wenn man kurz nachdenken wollte oder man eine kleine Diskussion startete. Am Ende haben wir uns bei Zeiten zwischen 6-8 min eingependelt. Das war für uns genug Zeit, um etwas zu erreichen, aber auch, um mal eine kleine Diskussion zu führen.Als hundertprozentiges Remote-Team mussten wir uns auch nebenbei noch eine Lösung suchen, um die Driver-Navigator-Wechselzeiten zu verbessern (Push des Codes zu einem dedizierten Git-Branch, Wechsel des Screensharings, etc.). Wir haben sie mittels Bash-Skripten und Disziplin auf ca. 30 Sekunden reduziert. Bei Timern unter 6 min ist das auch ein signifikanter Aspekt.Auch haben wir verschiedene Driver-Navigator-Methoden ausprobiert. Viele Teams bleiben beim Navigator-Driver-Pattern. Wir haben nebenbei noch folgende Muster versucht:<ul><li>Navigator-Driver-Mob <a href="https://media.graphassets.com/SrV9dxGXSGyzdVIp9Add"><img loading="lazy" width="250" height="101" src="https://media.graphassets.com/SrV9dxGXSGyzdVIp9Add" alt="navigator-driver" /></a> Der Navigator wird zum Driver, der Driver tritt dem Mob bei, und der Nächste aus dem Mob wird zum Navigator.</li><li>Driver-Navigator-Mob <a href="https://media.graphassets.com/KFqQBkvTTfqLFBKTqnyM"><img loading="lazy" width="250" height="100" src="https://media.graphassets.com/KFqQBkvTTfqLFBKTqnyM" alt="driver-navigator" /></a> Der Driver wird zum Navigator, der Navigator tritt dem Mob bei, und der Nächste aus dem Mob wird zum Driver.</li><li>Driver-Mob-Navigator-Mob <a href="https://media.graphassets.com/5tS8fye9Qjmn0EXwcxw7"><img loading="lazy" width="250" height="115" src="https://media.graphassets.com/5tS8fye9Qjmn0EXwcxw7" alt /></a> Der Driver und der Navigator treten dem Mob bei und die zwei Nächsten des Mobs werden zum Driver und zum Navigator.</li></ul>Driver-Navigator-Mob wurde unser Standard, denn:<ul><li>Wenn jemand den Faden verlor, war hierbei die Chance groß, dass derjenige durch die Driver-Rolle wieder aufgegleist wird, bevor er zum Navigator wird.</li><li>Während des Wechsels ist es von Vorteil, wenn der Driver aus dem Mob kommt, da er bereits die nötigen Dateien etc. öffnen kann, bevor es zum Wechsel kommt.</li></ul>Aber wir fanden auch die anderen Muster interessant und zum Teil auch hilfreich. Haben wir schon erwähnt, dass wir es sehr mochten zu experimentieren?<h2>Psychologische Sicherheit im Mob Programming</h2>Die Forschung hat gezeigt, dass psychologische Sicherheit ein starker Prädiktor für die Teamleistung ist. Es ist ein angenehmes Gefühl, sagen zu können, was man denkt, und zu sein, wer man ist, ohne sich zu schämen oder Auswirkungen befürchten zu müssen. Die enge Zusammenarbeit hat uns geholfen, uns als Menschen zu verbinden. Selten gab es in unserem Team etwas wie den „Code eines anderen“, und jeder wusste und fühlte sich mit den Fähigkeiten und persönlichen Umständen des anderen wohl.Es ist uns gelungen, uns mehrmals persönlich zu treffen und zusammenzuarbeiten – was sehr vorteilhaft ist. Sich live treffen, abends gemeinsam ein Bier trinken, die Familie des Kollegen kennen lernen – das sind Dinge, die ein Team stärken und vereinigen.<h2>Die Ironie des Shared Everything und des Bus Factors</h2>Die Verwendung des Mob-Programming-Ansatzes als Teil einer „Shared Everything“-Mentalität kann sehr vorteilhaft sein. Im Laufe des Projekts stellten wir fest, dass sich unser Bus Factor unserer Teamgröße angenähert hatte. Mit anderen Worten: Man hätte im Grunde das gesamte Team auflösen müssen, damit das Wissen und die Fähigkeiten aus dem Projekt verloren gehen. Das ist phänomenal.Wir stellten auch eine hohe Zufriedenheit fest, die sich im Team verbreitete. Alle waren leidenschaftlich an den Experimenten und der Zusammenarbeit interessiert. Niemand fürchtete sich zu sagen: „Ich habe das nicht verstanden“, „Können wir das ändern?“ oder: „Wir sollten das mal so versuchen“.<div><a href="https://media.graphassets.com/qBaDhPZkS7ux2HNwRiRK"><img loading="lazy" src="https://media.graphassets.com/qBaDhPZkS7ux2HNwRiRK" alt="leaving" width="1024" height="372" /></a> Bild von Ryan Tang, unsplash</div>Ein hoher Busfaktor schützt das Team, falls die Leute es verlassen. Die Ironie dabei ist jedoch, dass, wenn ein „Shared-Everything“-Team gebildet wird, niemand das Team verlassen will. Wir hatten während dieses Projekts keine Fluktuation in unserem Team.Trotz der wirklich interessanten Technologien und des kooperativen Kunden, der an dem Projekt beteiligt war, fasste ein Teammitglied am Ende des Projekts das Gefühl des Teams mit den Worten zusammen: „Ich bin wirklich traurig, dass dieses Projekt zu Ende geht. Nicht wirklich wegen der Projektarbeit, sondern weil ich das Team verliere.“

Mob Programming und Shared Everything

<h4>The coronavirus is thrusting society towards digitalisation. Expect many changes to remain long after the crisis has gone.</h4>Mike Chang, Product Owner at Altoread (names changed) briefed his technical staff last week in regards to COVID-19: “We need to prepare for traffic at up to 4x normal levels…”Altoread offers readers computer and smartphone-based alternatives to traditional paper books. As libraries shut their physical buildings over the past weeks, they pointed their readers towards such digital services.But the second half of Mike’s statement was the most interesting part: “We are expecting this to be a permanent change. After the crisis, traffic will not fall again.”COVID-19 has already had a dramatic effect on the world. But much more is to come. As governments prepare to spend “unlimited” amounts of money to prop up their economies, people around the world in various stages of lockdown are being forced to find new ways to get on with work and daily life. They are charting new waters, waters which in many cases, no amount of persuasion up to this point had caused them to venture into. And be it video conference, grocery delivery or online shopping, those waters are almost exclusively digital services.Many of the old, non-digital habits will return after COVID-19 is gone, but some won’t. In 2014, a strike on the London Underground closed some tube lines, forcing commuters to create new itineraries using the remaining lines to get to work and back. <a href="https://www.cam.ac.uk/research/news/london-tube-strike-produced-net-economic-benefit" target="_blank">A study</a> by Oxford and Cambridge universities revealed that after the strike had ended, 5% of passengers continued using their new itinerary, apparently preferring it to their previous route. Could something similar happen in the online space after coronavirus?<h2>Digitalisation by force</h2>The world was already on a trajectory of going digital. This inevitable change nevertheless takes time. People stick to their old habits, and it’s quite difficult for firms to persuade them to try something new. Grocery shopping is a case in point. In the US, Target famously used customer loyalty-card data to predict, with impressive accuracy, which of its shoppers were in their second trimester of pregnancy. They then bombarded these ladies with promotional material intended to influence them to switch to Target as their main household shopping source. The second trimester of pregnancy, science has revealed, is one of the few times in life that people are especially open to breaking old habits and forming new ones.The novel coronavirus has put us into a similar situation, though rather by necessity and force than by hormones or nature. In Spain and some other European countries, police and the armed forces are patrolling the streets and enforcing the lockdown. There is no longer an option to resist digitalisation and avoid “new-fangled stuff”. You no longer have a choice to support your local bricks-and-mortar book seller. You are literally being forced to conduct business online by people carrying guns. That beats even the second trimester.<div><a href="https://media.graphassets.com/8Ysta1r5TZWw3MBAoSB1"><img src="https://media.graphassets.com/8Ysta1r5TZWw3MBAoSB1" alt="Man sweats at computer while armed and masked men say &quot;Just order online&quot;" width="700" height="323" /></a> This gives a new meaning to “One-Click Ordering”. Comic by <a href="https://blog.codecentric.de/en/author/florian-schneider/">Florian Schneider</a> .</div><h2>Ordering a New World</h2>The effect is being felt in digital demand. Amazon is employing 100,000 new warehouse and logistic workers to deal with the increase in orders. Microsoft Teams remote collaboration software has stuttered under sudden demand, whilst the share price of Zoom, a video communications service, has rocketed against the backdrop of a wider market freefall. And as for grocery shopping, Woolworths, an Australian supermarket, has suspended online shopping and delivery in some regions, unable to cope.<div><a href="https://media.graphassets.com/pxV941eXSZGsMx24wKcI"><img loading="lazy" src="https://media.graphassets.com/pxV941eXSZGsMx24wKcI" alt="Empty pasta shelves at a supermarket during COVID-19 crisis" width="640" height="480" /></a> Perhaps shoppers who only know how to cook pasta are preparing for Italy to disappear</div>The changes are everywhere. Teachers are sharing their contact details with students in order to be able to instruct them remotely, previously a taboo idea for many in their attempt to strictly separate work and private life. Churches are holding services entirely online. “Ghost” music concerts (be it <a href="https://twitter.com/JamesBlunt/status/1238500843030302721" target="_blank">pop</a> or classical) are being played in empty theatres and broadcast for free. Tomorrow <a href="https://live.theleaddev.com/" target="_blank">Lead Dev Live</a> will kick off, one of many free online events created to replace a cancelled in-presence conference; over 10,000 people have signed up. Localised small interest groups have switched to online.Before Corona, aficionados would probably have told you that these events can only be conducted in-person. Isn’t the entire purpose of church, or a software conference, physically coming together to socialise, interact and exchange ideas? Live-recorded music concerts were always just a flavour of recorded music. Homeschooling is/was either banned or vaguely tolerated in most countries. But when it’s virtual or nothing, virtual suddenly has virtue.<h2>Borders close. Online communities open.</h2>These approaches are already opening new horizons. This month, codecentricer Chris Dutz will present live from his home in Frankfurt, Germany at the Melbourne, Australia IoT meetup. The Lead Dev London could never have handled so many attendees at the physical conference – this newfound reach might be something the organisers would like to continue. Will virtual meetups continue after the crisis, defined by time and language rather than by region? In the education space homeschooling is unlikely to take off, but expect to see a few new methods filter through into normal practise after the crisis.<div><a href="https://media.graphassets.com/19egvtXbS3mS0oIQqVva"><img loading="lazy" src="https://media.graphassets.com/19egvtXbS3mS0oIQqVva" alt="A video conference" width="600" height="263" /></a> As long as each participant in a video conference remains 1m from his monitor, the mandated 2m is maintained between any two participants at all times.</div>Earlier in the crisis, when social distancing was only beginning to be encouraged, there were reports on Twitter of managers continuing to insist that employees come to the office, because permitting employees to work from home “might create a precedent”. In other words, after COVID-19 crisis has passed, people might ask their bosses why they shouldn’t continue to <a href="https://blog.codecentric.de/en/category/remote/">work from home</a> : “I avoided a long commute, I was able to work without distractions, and as you can see, I got more done than ever.”Assuming the reports are true, these managers are spot on. Employees will request this and more, and citizens will make other changes. The net effect on society is going to be a sudden jump forward in digitalisation, where heretofore unreachable people, having broken down the mental or cultural barrier, jump on the train of online shopping, banking and other services.<h2>Reopening unemployment</h2>Sadly, many of the businesses which are hardest hit right now will also carry the cost of this change forever. Bricks and mortar stores might struggle to reopen, only to find that 10% of their customers have permanently disappeared. Employee layoffs could create structural unemployment – a situation in which existing skills have become irrelevant and previously talented people become unemployable. It’s not an easy problem to solve, and governments will be further restricted in their ability to help by the debt which they have racked up during their “save the economy” spending sprees.The future is bright for digitalisation enablers like codecentric. Management consults tell me of their attempts to convince heads of business that they are not, for example, a bank which has some supporting IT, they are an IT company which offers banking services. This message is getting easier to understand. The need for digital enablement support in every type of company will only increase.Hopefully, companies like codecentric can also help with the structural unemployment. We can’t work miracles with totally unqualified people, but we do try hard to make our hiring as inclusive as possible – the qualifications to work with us are soft rather than hard. Demonstrating initiative and a deep desire to learn can be worth more to us than a university degree. Besides listing open positions, we also accept applications for any unlisted job – maybe <a href="https://www.codecentric.de/karriere/" target="_blank">we need you</a> and we just don’t know it yet.As for those digital reading services, Altoread is perfectly positioned to handle the surge in demand from the bunkered-down bookworms. codecentric helps them to run their digital services as a cloud-native company. This enables them to automatically scale their IT infrastructure up to cope with surges in customer traffic. As the traffic drops again, the systems scale back down. That is, if the traffic ever drops down again.

Death, downturn and dramatic digitalisation – COVID-19’s legacy-to-be

Mob programming is a technique we use extensively for sharing knowledge in the team, improving developer skills and increasing team cohesion. These might not be the primary goals of your business, but they probably contribute much more than you realise to achieving your goals. In this article, we share the techniques we have developed to make Mob programming feasible, fun and effective.<h2>“Shared everything”</h2>In a recent project, we introduced mob programming as part of our goal to share everything inside our team. We wanted to have all developers on the same level, rather than having titles, categorisations and specialisations. As a result of consistently applying a “shared everything” mindset, our team’s “bus factor” approached the team size.<h2>Bus factor?</h2><div><a href="https://media.graphassets.com/vcASUP2US3ypx1fWG0x6"><img src="https://media.graphassets.com/vcASUP2US3ypx1fWG0x6" alt="bus factor" width="1024" height="1024" /></a> – Image by Lai Man Nung - unsplash</div>In any team, there are individuals who are the sole possessors of specific knowledge, knowledge which is essential to the team’s performance and the outcomes. If these people were to suddenly leave the team, the team would suffer.The bus factor of a team is the number of team members that would need to be “hit by a bus” before the team would end up in serious trouble.So the bus factor indicates how healthy your team is regarding knowledge transfer and skill sharing. A high bus factor indicates healthy knowledge sharing and a healthy team.How did we apply mob programming and “shared everything”?<h2>Mob programming – An adventure</h2><div><a href="https://media.graphassets.com/TcK4szlwRg2bBnWxfRXX"><img loading="lazy" src="https://media.graphassets.com/TcK4szlwRg2bBnWxfRXX" alt="remote mob session" width="1024" height="640" /></a> – Remote mob programming session – Screenshot by the authors</div>During the project in question, we were lucky enough to use DDD (Domain Driven Design), TDD (Test Driven Development), and more importantly mob programming techniques.<a href="https://media.graphassets.com/VTdOSJtJQeiS1WqvFls9"><img loading="lazy" src="https://media.graphassets.com/VTdOSJtJQeiS1WqvFls9" alt="mob-in-a-nutshell" width="1024" height="867" /></a> Mob programming in a nutshell: You have one computer and three or more developers. One is typing (driver), one or the rest of the developers lead the driver and give commands (navigator-s). The whole team is working on the same issue at the same time. See the different mob programming modes in the experiment section.Initially we had a bumpy start. Mob programming felt completely different to the software development we were used to. A feeling that we might not be moving fast enough was repeatedly mentioned in retrospectives, and there was the frustration of not being able to take the keyboard and control. We tried it, abandoned it, restarted, and stopped again.In the beginning, we experimented a lot and were inspired by the <a href="http://www.mobprogrammingguidebook.com/images/mobprogrammingguidebook.pdf">Guide from Maaret Pyhäjärvi</a> .We started to see how knowledge was being transferred to every team member and code quality seemed to be increasing.Nevertheless, the challenges continued. Just when we were about to give up the idea for good, we had a great mob programming workshop with <a href="https://woodyzuill.com/">Woody Zuill</a> . This helped us to see how the technique allowed us to develop as people and as a team, and we were enthusiastic again! Among the many ideas we picked up from Woody was the practice of a daily retrospective. Generally we did this at about 4pm and tried to keep it to 5 minutes. In the daily retro everyone said something which went positive during the day. To get used to it, we needed to set up an alarm.We needed to focus on remote mob programming, because the team members were spread over different locations. Here we got inspired by a <a href="https://www.remotemobprogramming.org/">remote mob programming guide</a> from Simon Harrer, Jochen Christ, and Martin Huber. We needed to establish a few rules …<h3>Some “shared everything” rules</h3><ul><li>Camera always on <div><a href="https://media.graphassets.com/sVvcOf0SgiV23REl1cib"><img loading="lazy" src="https://media.graphassets.com/sVvcOf0SgiV23REl1cib" alt="webcam" width="1024" height="387" /></a> – Image by Aksa2011, pixabay</div>Since the team was spread over several locations, it was important for us to define the “Camera always on” rule. That helped that all team members felt like first-class citizens. It gives you a better ‘we’ feeling, especially for the remote members. Additionally, it promotes a better understanding in discussions and meetings, because you will get the gestures of the speaking person. Which brings us to the next rule…</li></ul> <ul><li>30-second rule <div><a href="https://media.graphassets.com/oEQjn2jRbq6UtqaQlPLf"><img loading="lazy" src="https://media.graphassets.com/oEQjn2jRbq6UtqaQlPLf" alt="timer" width="1024" height="358" /></a> – Image by Aron Visuals, unsplash</div>If a person speaks for more than 30 seconds off-camera, the meeting must be interrupted in order to force corrections. Since every one of us in our primary project office had their own notebook with a camera, most of the time everyone was on camera by default. However, typically stakeholders would visit us for meetings. In order to enforce our “shared everything” philosophy, everyone needed to participate in these meetings on equal footing. It was critical to adjust our setup so that all the guests in the room could clearly be seen by the remote members/participants. Whether for catching body language or simply for being aware of who exactly was speaking, this rule makes a difference like night and day. So, the extra persons were distributed to the existing notebooks (cameras), before the meeting started. The stakeholders were extremely co-operative.</li></ul> <ul><li>10-minute rule <div><a href="https://media.graphassets.com/hLRSuRTtSsyMGTgQQsIZ"><img loading="lazy" src="https://media.graphassets.com/hLRSuRTtSsyMGTgQQsIZ" alt="speaking" width="1024" height="355" /></a> – Image by Clem Onojeghuo, unsplash</div>If a remote participant doesn’t say anything for 10 minutes, stop the meeting and ask them to say something or summarise the last minutes. Sure, that is a hard rule, but for us it was important that everyone understood the matter of the meetings and kept the knowledge spread. If someone doesn’t talk for a while, it’s usually an indicator that they have lost track of what is going on.</li></ul> <ul><li>Do you need a break? Take one. <div><a href="https://blog.codecentric.de/files/2020/02/break_unsplash_alex-scaled.jpeg"><img loading="lazy" src="https://media.graphassets.com/Tt1WsMZmRXqkIkE4VKy0" alt="break" width="1024" height="368" /></a> – Image by Alex, unsplash</div>Mob programming needs high attention and focus, and learning is tiring. Everyone in the team should be allowed to take a break whenever it is needed. The positive thing while doing mob programming is that this person will get back into the flow quickly. We tried various break techniques, and generally settled on the “individual breaks” technique. We generally synchronised lunch, but otherwise there were no agreed breaks. Any person could take a short break whenever they felt it was necessary. When they came back we simply put them on the end of the list. This avoided discussion and organisation. And the person could get in again easily.</li></ul>For business meetings of course, you need to take breaks together. Here we established another rule – the “45-minute rule”, which basically meant a forced break every 45 minutes. Meetings are quite stressful for remote participants who are not speaking their native language. This helps them to stay tuned in.The rules above helped us a lot while doing mob programming. And mob programming helped us a lot to spread all the knowledge to every single team member. So, everyone on this team knows every small corner of our application and was able to work on every part of it.<h2>Experiments for the win</h2>As we mentioned earlier, we did a lot of experiments. Experiments are fun. So, for example, we tried to do mob programming in three different ways which we learned as “Dojos” from Woody Zuill during his workshop. We called them strict, soft, and freestyle. <ul><li>Strict <a href="https://media.graphassets.com/aLFbgfSTSeKvUiNeZHiY"><img loading="lazy" src="https://media.graphassets.com/aLFbgfSTSeKvUiNeZHiY" alt="mob-strict-mode" width="250" height="117" /></a> The strictest implementation of the driver-navigator pattern. Only the navigator is allowed to speak, others simply watch. Literally, they may not speak, even to answer questions.This very quickly becomes frustrating for the mob as they see the navigator struggling but are not allowed to give them any answers. Surprisingly, this can create great benefits. The navigator learns to think out loud so that the next navigator can easily take over. Asking the mob questions (which go unanswered) is a surprisingly effective method of communication.The mob learns patience, and the vital art of letting someone else have a go; trying someone else’s ideas out. Once you learn to handle the frustration, you find that this is the most peaceful technique of all. No discussion, no arguments. Just coding and trying to understand each other.</li></ul> <ul><li>Soft <a href="https://media.graphassets.com/EcCuXNZcSF2VpSwJA6Nk"><img loading="lazy" src="https://media.graphassets.com/EcCuXNZcSF2VpSwJA6Nk" alt="mob-soft-mode" width="250" height="125" /></a> This is similar to the strict technique, but the mob is allowed to speak when requested by the navigator. They can answer questions and also raise their hands and wait until they are asked to speak. This removes some of the seeming stupidity of the strict technique when you watch a teammate flounder. However, if you are not careful, this technique can degrade into long discussions and “freestyle”.</li></ul> <ul><li>Freestyle <a href="https://media.graphassets.com/SrV9dxGXSGyzdVIp9Add"><img loading="lazy" src="https://media.graphassets.com/SrV9dxGXSGyzdVIp9Add" alt="mob-freestyle-mode" width="250" height="116" /></a> In freestyle mode there is one driver and the rest of the team members are navigators. Everyone is free to give a command, mention an idea, or start a discussion. We found that in this mode it was important to apply techniques to reduce discussion. One such technique is just accepting the idea of a colleague and trying it out to prove it good or bad, instead of discussing it to death. Often the result is surprising!</li></ul>We think we ended up in the soft mode most often – a good compromise between other techniques. Freestyle felt like a natural thing to do a bit every day too. But, we found that we had to reserve a time slot (maximum of 1 hour) for doing the strict mode because we valued this training in solution finding and patience, but one doesn’t just accidentally fall into doing something that feels so unnatural.We also experimented with the mob programming time. So, we tried to set the timer to a very low (2-3 minutes), medium (5-12 minutes), and high (15-25 minutes) time. And then we started to mob for 1 to 2 rounds. We figured out that a timer set too high will cause followers to lose their focus. Also, too low times are bad because you start, think about something, start a small discussion and boom …. the time is over. At least, we stick to 6-8 minutes for a driving round. It was enough time for us to get something done, but also to discuss a little about an idea.As a remote team, we also had to factor in the overhead of switching (pushing to a dedicated Git branch, switching screen sharing). We managed to reduce this to 30 seconds when we were disciplined, but no further. So with a timer of less than about 6 minutes, this became a significant aspect.<h3>What about the mob programming patterns</h3>Another thing we tried are different ways of driver-navigator patterns. Many teams are stuck on the navigator-driver-mob pattern. We tried every possible variation: <ul><li>Navigator-driver-mob <a href="https://media.graphassets.com/KFqQBkvTTfqLFBKTqnyM"><img loading="lazy" width="250" height="101" src="https://media.graphassets.com/KFqQBkvTTfqLFBKTqnyM" alt="navigator-driver" /></a> The navigator becomes the driver, the driver joins the mob, and the next out of the mob becomes the navigator.</li></ul> <ul><li>Driver-navigator-mob <a href="https://media.graphassets.com/5tS8fye9Qjmn0EXwcxw7"><img loading="lazy" width="250" height="100" src="https://media.graphassets.com/5tS8fye9Qjmn0EXwcxw7" alt="driver-navigator" /></a> The driver becomes the navigator, the navigator joins the mob, and the next out of the mob becomes the driver.</li></ul> <ul><li>Driver-mob-navigator-mob <a href="https://media.graphassets.com/qBaDhPZkS7ux2HNwRiRK"><img loading="lazy" width="250" height="115" src="https://media.graphassets.com/qBaDhPZkS7ux2HNwRiRK" alt /></a> The driver and the navigator join the mob and the next two of the mob become the driver and the navigator.</li></ul>Driver-navigator-mob became our default order, because:<ul><li>If someone lost touch with what was going on, they had a better chance to mentally get back into it as a driver before becoming navigator. </li><li>The changeover friction is reduced when the driver comes from the mob. They can ensure they have the right programs and classes open 30 seconds before changeover, which isn’t practical when they’re trying to navigate.</li></ul>However, at various times we found the other patterns to be interesting and helpful. Did we mention it before? We loved to experiment.<h2>Psychological safety</h2>Research has shown that psychological safety is a strong predictor of team performance. This is basically feeling comfortable to say what you think and be who you are without embarrassment or fear of repercussions. Collaborating together so closely helped us bond as people. There was rarely such a thing as “someone else’s code”, and everyone knew and was comfortable with everyone else’s capabilities and personal circumstances.We managed to meet and work together in person a number of times – something which is very beneficial. Meet live, have a beer together in the evening, meet the family of your colleague – these are things which strengthen a team into a unit.<h2>The irony of shared everything and bus factor</h2>Using the mob programming approach as part of a “shared everything” mindset can be very beneficial. As the project went on, we noticed that our bus factor had approached our team size. In other words, you would basically need to remove the entire team for the knowledge and skills to be lost from the project. This is quite a phenomenal result.We also discovered a high satisfaction spread through the team. Everyone was passionate about doing the experiments and working with each other. No-one feared to say “I didn’t get this”, “could we change this?” Or, “we should try this”.<div><a href="https://media.graphassets.com/JH8qK7MYRqiTgqGXXrdz"><img loading="lazy" src="https://media.graphassets.com/JH8qK7MYRqiTgqGXXrdz" alt="leaving" width="1024" height="372" /></a> – Image by Ryan Tang, unsplash</div>High bus factor protects the team in the case that people leave it. Yet the irony of this is, when a “shared everything” team is established, no-one wants to leave. We had no fluctuation in our team during that project.Despite the really interesting technologies and co-operative customer involved in the project, at the end of the project one team member summed up the team feeling by saying “I’m really sad that this project is ending. Not really because of the project work, but because of losing the team”.

Mob programming and shared everything

Weitere Infos

Details

Sprich mich gern an

Komm zu unserer Konferenz, ich freue mich auf den Austausch mit dir! Hast du vorher schon Fragen?

Vielen Dank für deine Anfrage. Ich melde mich bei dir.

Vielen Dank für deine Anmeldung. Eine E-Mail zur Bestätigung ist zu dir unterwegs.

Diese Seite ist eine Vorschau. \nKlicken Sie hier\n, um den Vorschaumodus zu verlassen.

Zu deiner Suche haben wir leider keine passenden Blogartikel gefunden. 

Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.

Die \nDatenschutzerklärung\n der codecentric AG habe ich zur Kenntnis genommen und bestätige das mit der Absendung des Formulars.*

Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.

Ich möchte eure Inhalte abonnieren. Diese Einwilligung kann ich jederzeit widerrufen bzw. den Blog Newsletter abbestellen. Die Datenschutzerklärung habe ich gelesen. Ich bin damit einverstanden, dass die codecentric AG, Hochstr. 11, 42697 Solingen, mich über eigene Dienstleistungen, branchenrelevante Events, Webinare und Publikationen der codecentric AG über die von mir angegebene E-Mail-Adresse informiert. Meine Einwilligung ist freiwillig. Ich kann meine Einwilligung jederzeit mit Wirkung für die Zukunft widerrufen (z.B. über den hierfür vorgesehenen Abmeldelink in unserem Newsletter, per E-Mail an datenschutz@codecentric.de oder per Post an die oben genannte Adresse der codecentric AG) erklären. Weitere Hinweise zur Verarbeitung meiner personenbezogenen Daten und zu meinen Rechten als betroffene Person finde ich hier: \nhttps://www.codecentric.de/datenschutzerklaerung\n

Bitte wähle deine/n gewünschte/n Standort/e aus.

Wir möchten dich als Mensch kennenlernen. Erzähle uns, wer du bist, worauf du Wert legst, wie du gerne arbeitest und was du von uns als Arbeitgeber erwartest.

Bitte füge deine Bewerbungsunterlagen ​(mind. Lebenslauf, gerne auch mehr)​​ ​als eine ​PDF-​Datei ​hinzu.

Ich habe die \nDatenschutzbestimmungen\n und die Einwilligung in die Datenverarbeitung gelesen und stimme diesen zu.*

Job application form field placeholder 10

Keine passende Rolle gefunden? Bewirb dich bitte trotzdem initiativ! Jenseits von starren Schubladen zählen für uns vielmehr Motivation, Kompetenz und der Cultural Fit.

Job application form field placeholder 11

Dies ist ein Pflichtfeld, bitte fülle es aus.

Kontakt

Absenden

Guerilla Organisation Enablement - Developer-driven Transformation

CloudLand 2023

Weitere Infos

Details

Sprich mich gern an

Gemeinsam bessere Projekte umsetzen.

Wir helfen deinem Unternehmen.

Unsere Leistungen

Hilf uns, noch besser zu werden.

Zu den Jobangeboten