Logo der codecentric AG, einem in Deutschland führenden IT-Consulting Unternehmen

Logo der codecentric AG einem in Deutschland führenden IT-Consulting Unternehmen

Cloud-Native

Data & Machine Learning

Generative KI

Produktentwicklung

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

Kultur & Karriere Podcast

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.

Contact Us | Sub-Navi-Kontakt oder Zero Search Hits

Kontakt aufnehmen

Marketing & Community Management

Konntest du keine Einträge zu deinem Thema finden?  

Team oriented developer

Informatik aktuell

Webdevelopment

KTOR oder Spring Boot? Vergleich der Web-Frameworks

Für Informatik aktuell hat Florian Schneider die beiden Web-Frameworks KTOR und Spring Boot miteinander verglichen.

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/6WkAuzFHQRiKq47LrMhK"><img src="https://media.graphassets.com/6WkAuzFHQRiKq47LrMhK" 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/1SKF1LxS7e1Z5c9hetIJ"><img loading="lazy" src="https://media.graphassets.com/1SKF1LxS7e1Z5c9hetIJ" 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/tUYH0W7WTW6WFYyAAxwU"><img loading="lazy" src="https://media.graphassets.com/tUYH0W7WTW6WFYyAAxwU" 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/R2sNThTQyVw9SI6gXXJw"><img loading="lazy" src="https://media.graphassets.com/R2sNThTQyVw9SI6gXXJw" 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/WbA8HcIVSna2787xmZ9S"><img loading="lazy" src="https://media.graphassets.com/WbA8HcIVSna2787xmZ9S" 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/CJX3LjayTfKE2tUMnCYd"><img loading="lazy" src="https://media.graphassets.com/CJX3LjayTfKE2tUMnCYd" 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/d1arg0X5TWGL6pN8gGnF"><img loading="lazy" src="https://media.graphassets.com/d1arg0X5TWGL6pN8gGnF" 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

Ca. zwei Monate nach meinem Einstieg bei codecentric hatte ich ein wirklich interessantes Gespräch mit einem Kollegen. Ich glaube, es verlief folgendermaßen:Kollege: Hey, hast Du schon mal von YAGNI gehört? Ich: Gesundheit. Kollege: Was? Ich: Du hast doch gerade geniest? …Ich bin mir ziemlich sicher, dass das Gespräch so verlief. Aber im Ernst, er sagte mir, dass es für die effektive Entwicklung von Software entscheidend ist, YAGNI (You aren’t gonna need it) zu verstehen und anzuwenden. Ich sollte es ausprobieren und es in meinen aktuellen und nächsten Projekten verbreiten. Aber was in aller Welt ist YAGNI und warum sollte es mir bei der Software-Entwicklung helfen? Ich möchte euch in diesem Artikel einen kurzen Überblick geben und einige Erfahrungen mit euch teilen.<h2>You aren’t gonna need it!</h2>Er gab mir einen Website-Link [<a href="http://c2.com/xp/YouArentGonnaNeedIt.html" target="_blank">http://c2.com/xp/YouArentGonnaNeedIt.html</a> ], um mehr über YAGNI zu lesen. YAGNI ist also eine Extreme-Programming-Technik. Und eines der ersten Zitate auf der Website sagt eigentlich alles aus, was man wissen muss:<blockquote>Implementiere die Dinge immer dann, wenn du sie tatsächlich brauchst, niemals, wenn du nur voraussieht, dass du sie brauchen könntest.</blockquote>Moment, was? Das ist einfach und genial zugleich. Als ich diesen Satz las, hatte ich direkt ein euphorisches Gefühl und war sofort vom YAGNI-Virus infiziert.<a href="https://media.graphassets.com/P854jxRGNxPAjjz4GWgP"><img src="https://media.graphassets.com/P854jxRGNxPAjjz4GWgP" alt="softwarepiece" width="1024" height="683" /></a> Wie oft habe ich in der Vergangenheit, bevor ich diesen Ansatz kannte, so etwas gedacht: „Was könnte mit meiner Software in der Zukunft passieren? Oh ja, vielleicht dies und das. Lass uns einfach all diese Dinge implementieren, da wir sowieso gerade daran arbeiten. Dann ist es zukunftssicher.“ Und was geschah dann? Richtig, die implementierten Funktionen, die auf Annahmen basierten, funktionierten nicht wie vom Kunden oder Benutzer erwartet. Also mussten wir am Ende einige Teile der Software neu implementieren, um das zu beheben. Und manchmal kommt es vor, dass ein Teil der Software aus bestimmten Gründen zukünftig nicht mehr benötigt oder verwendet wird.Hier kann YAGNI helfen: indem ihr Dinge erst dann implementiert, wenn sie gebraucht werden. Damit könnt ihr euch Zeit und unnötige Arbeit bei der Implementierung sparen und unnötige Wartung des Codes vermeiden.Das gleiche Prinzip gilt sowohl auf der geschäftlichen Ebene, wie z. B. bei den Produktfunktionen, als auch auf der Implementierungsebene, wie z. B. bei den Software-Abstraktionen. Schreibt ihr nur eine Klasse oder erstellt ihr bereits eine abstrakte Klasse mit einer Child-Klasse, weil ihr vermutet, dass in Zukunft noch mehr Child-Klassen kommen werden?<h2>Würde YAGNI in den Projektalltag passen?</h2>Kurze Antwort: Auf jeden Fall. Bei einem kürzlich durchgeführten Projekt waren der oben genannte Kollege und ich in der glücklichen Lage, demselben Team beizutreten. Und er hat auch dort das YAGNI-Prinzip gleich zu Beginn dem Rest des Teams vorgestellt. Es war interessant zu beobachten, wie diese Technik zu einer Art Herausforderung wurde. Sehr oft hörten wir jemanden sagen: „Warte, brauchen wir das wirklich jetzt?“. Das war sehr cool. Sie waren alle mit diesem YAGNI-Virus infiziert. Eines unserer neuen Teammitglieder schuf sogar einen Post-It-Schrein an der Wand des Büros.<a href="https://media.graphassets.com/9op4M3EeThe3O8ib5anS"><img loading="lazy" src="https://media.graphassets.com/9op4M3EeThe3O8ib5anS" alt="yagni do-we-really-need-it" width="1024" height="265" /></a> Ein großer Vorteil von YAGNI ist es, unnötige Entwicklungen zu vermeiden. Wenn man darüber nachdenkt, entwickelt man sicherlich oft Software auf der Grundlage von Annahmen. Wenn man über zukünftige Funktionen nachdenkt, kann es auch manchmal Unklarheiten geben. Ich habe die Erfahrung gemacht, dass auch der Kunde sagte: „Ja, wir brauchen jetzt die Funktion X“, und wenn man nach den Anforderungen an diese Funktion fragte, hörte man als Antwort manchmal so etwas wie „Oh, das ist im Moment nicht hundertprozentig klar“. Das sollte eine Warnung sein. Diese Dinge sind genau das, wofür YAGNI steht. Verschiebt diese Anforderung auf einen späteren Zeitpunkt des Projekts. Dann könnten die Anforderungen klarer sein und ein Feature könnte genauer bzw. gezielter entwickelt werden.<a href="https://media.graphassets.com/nB3onXLgQRGYRXOmVn7h"><img loading="lazy" src="https://media.graphassets.com/nB3onXLgQRGYRXOmVn7h" alt="yagni-mindset" width="1024" height="383" /></a> Aber … es gibt immer ein „aber“ … es ist manchmal nicht so einfach. Es ist harte Arbeit, eine YAGNI-Mentalität in einem Team und bei einem Kunden zu verbreiten. Ihr solltet immer wieder versuchen, euer Gegenüber herauszufordern. Fragt euch selbst, euer Team und den Kunden: „Brauchen wir das wirklich (jetzt)?“. Wenn euer Gegenüber Schwierigkeiten hat oder nicht klar ist, warum etwas benötigt wird, dann ist dies ein Indikator, dass YAGNI helfen kann. Und dann solltet ihr auch darüber nachdenken, es zu verschieben oder auf Eis zu legen, bis es wieder wichtig wird. Das bedeutet nicht, dass die Dinge nicht wichtig sind, aber sie sind vielleicht zu einem frühen Zeitpunkt noch unklar. Wenn sie zu einem späteren Zeitpunkt wichtiger werden, dann könnte auch die Reife dieses Themas ausgeprägter sein. Es könnte für den Kunden relevanter werden, und es könnten genug Details für eine Umsetzung geben.Was YAGNI nicht bedeutet, ist, dass ein Feature niemals implementiert wird, nur weil es jetzt nicht notwendig ist. Es soll euch nur dabei helfen, Prioritäten zu setzen und zu vermeiden, dass ihr jetzt auf der Grundlage von Annahmen arbeitet, mit der Gefahr, es später zweimal zu tun, weil es im Moment falsche oder zu wenige Informationen gibt.Wenn ihr YAGNI verwendet, könntet ihr auch das Gefühl bekommen, dass es euch davon abhalten könnte, Experimente durchzuführen. Das wäre richtig, wenn ihr die YAGNI-Methodik bei der Erstellung von Prototypen ignoriert. Der bessere Weg ist, wenn ihr die Technik zum Fokussieren verwendet. Quasi während ihr einen Prototyp erstellt. Und hier wäre es völlig in Ordnung, wenn man dieselbe Arbeit zweimal machen würde. Dann könnt ihr aus dem Feedback lernen, und vielleicht ist der Prototyp auch manchmal nicht das, was der Benutzer oder Kunde erwartet. Das führt sehr schnell dazu, dass die Idee verworfen wird und man es noch einmal implementiert. Aber das ist völlig in Ordnung, und während der Durchführung von Versuchen solltet ihr auch YAGNI einsetzen, um euer Ergebnis nicht zu überfrachten. Wie auch immer, beim Prototyping geht es darum, etwas auszuprobieren und sich bewusst zu sein, dass es am Ende weggeworfen wird.<h2>Fazit</h2>Für mich ist YAGNI eine ausgezeichnete Möglichkeit, den Software-Entwicklungszyklus zu verbessern. Es hilft sehr, sich auf die notwendigen Funktionen und Software-Artefakte zu konzentrieren. Ihr solltet es für Experimente (Prototyping) verwenden und euch dabei bewusst sein, dass Software-Artefakte möglicherweise mehrfach implementiert werden müssen. Ich finde, dass YAGNI und Prototyping perfekt zusammenpassen. Und nun sucht euch etwas, was vereinfacht werden muss!

YAGNI – Eine kurze Einführung und ein Erfahrungsbericht

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/IStAzEB4R1mKwRHkdBqX"><img src="https://media.graphassets.com/IStAzEB4R1mKwRHkdBqX" 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/ai9qU79SShqHkJODAYIB"><img loading="lazy" src="https://media.graphassets.com/ai9qU79SShqHkJODAYIB" 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/nBsdt2CKTaugEPav2jx7"><img loading="lazy" src="https://media.graphassets.com/nBsdt2CKTaugEPav2jx7" 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/e0m2vVsRpm7JwKHyBrSw"><img loading="lazy" src="https://media.graphassets.com/e0m2vVsRpm7JwKHyBrSw" 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/DmyvaY7MSeUbmWwdKoK3"><img loading="lazy" src="https://media.graphassets.com/DmyvaY7MSeUbmWwdKoK3" 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/CG2UQ6nQnyZQkH1pFB4w" 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/DuweXxQduW8qtM8Yukzw"><img loading="lazy" width="250" height="117" src="https://media.graphassets.com/DuweXxQduW8qtM8Yukzw" 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/uydRh5SZR3yPGmd2bK4M"><img loading="lazy" width="250" height="125" src="https://media.graphassets.com/uydRh5SZR3yPGmd2bK4M" 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/fKtb40bTIOMGAHY3x1Vj"><img loading="lazy" width="250" height="116" src="https://media.graphassets.com/fKtb40bTIOMGAHY3x1Vj" 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/mYat3uvTS7lsyLYq9INA"><img loading="lazy" width="250" height="101" src="https://media.graphassets.com/mYat3uvTS7lsyLYq9INA" 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/6GDWeccZRiq1Cc0vMH4N"><img loading="lazy" width="250" height="100" src="https://media.graphassets.com/6GDWeccZRiq1Cc0vMH4N" 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/RAGYBbtkSCiCaeFqzPsp"><img loading="lazy" width="250" height="115" src="https://media.graphassets.com/RAGYBbtkSCiCaeFqzPsp" 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/LxVateSEOpHjgdvdHkow"><img loading="lazy" src="https://media.graphassets.com/LxVateSEOpHjgdvdHkow" 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

About two months after I joined codecentric, I had a really interesting conversation with a colleague. I think it went like this:Colleague: Hey, have you ever heard of YAGNI? Me: Bless you! Colleague: What? Me: Did you just sneeze? …I am pretty sure that the conversation was like that. But seriously, he told me that in order to develop software effectively, it’s critical to understand and apply YAGNI, which is short for: “You Aren’t Gonna Need It”. I should try it and use it inside my current and upcoming projects, he said. But what on earth is YAGNI and why should it help me in software development? In this article, I would like to give you a quick overview and share some experiences.<h2>You aren’t gonna need it!</h2>My colleague gave me a website link [<a href="http://c2.com/xp/YouArentGonnaNeedIt.html" target="_blank">http://c2.com/xp/YouArentGonnaNeedIt.html</a> ] to read more about YAGNI. So, YAGNI is an extreme programming technique. And one of the first quotes on the website tells you everything you need to know:“Always implement things when you actually need them, never when you just foresee that you need them.”Wait, what? That is simple and genius at the same time. When I read that sentence it gave me a mind-blowing feeling and I was instantly infected with the YAGNI virus.<a href="https://media.graphassets.com/P854jxRGNxPAjjz4GWgP"><img src="https://media.graphassets.com/P854jxRGNxPAjjz4GWgP" alt="softwarepiece" width="1024" height="683" /></a> Often, in the past, before I knew that approach, I thought something like: “What could happen with my software in the future? Oh yeah, maybe this and that. Let’s implement all these things since we are working on this part anyway. That way it’s future-proof” And what happened afterwards? Right, the implemented features, based on assumptions, didn’t work as expected by the customer or user. So in the end we had to reimplement some parts of the software to fix that. And sometimes it happens that a piece of the software is not needed or used in the future, because of reasons.This is where YAGNI can help. By not implementing things until you need them, you can save time and prevent useless work implementing and maintaining this code.This same principal applies on both a business level, such as product features, and on an implementation level, like software abstractions. Do you just write a class, or do you already create an abstract class with one child class because you suspect more children will come in the future?<h2>Would YAGNI fit into your daily project life?</h2>Short answer: absolutely. In a recent project, the above mentioned colleague and I were in the lucky situation to join the same team. And he also introduced the YAGNI principle to the rest of the team at the very beginning. It was interesting to observe how this technique was a kind of a challenge. Very often we heard someone say: “Wait, do we really need that now?”. That was amazing. They were all infected with that virus, too. One of our new team members also created a Post-It shrine at the office wall.<a href="https://blog.codecentric.de/files/2020/02/img_2990-scaled.jpg"><img loading="lazy" src="https://media.graphassets.com/9op4M3EeThe3O8ib5anS" alt="yagni do-we-really-need-it" width="1024" height="265" /></a> A big advantage of YAGNI is that you avoid unnecessary development. If you think about it, you certainly often develop software on the basis of assumptions. Also, sometimes when you think about future features, there could be obscurities. I have heard customers say “Yeah, we need feature X now”, and when you ask what the requirements for this feature are, you sometimes get an answer like “Oh, that is not 100% clear at the moment”. This should alert you. Those things are exactly what YAGNI stands for. Postpone them to a later state of the project when requirements are more clear and a feature can be developed more accurately.<a href="https://media.graphassets.com/nB3onXLgQRGYRXOmVn7h"><img loading="lazy" src="https://media.graphassets.com/nB3onXLgQRGYRXOmVn7h" alt="yagni-mindset" width="1024" height="383" /></a> But … there is always a “but” … sometimes it is not that easy. It is hard work to spread a YAGNI mindset in a team and propagate it to a customer. Over and over, you should try to challenge your opposite. Ask yourself, your team, and your client: “Do we really need this (now)?”. Whenever your counterpart struggles or doesn’t have a clear standing why something is needed, it’s clearly time for YAGNI. Then you should also think about discarding it or put it on hold until it becomes relevant again. This doesn’t mean that things aren’t important, but they are maybe still unclear at an early point in time. When they become more important at a later point, the maturity of this issue might also have grown. It might become more relevant for the client and there could be enough details for an implementation.What YAGNI does not mean is that a feature will never be implemented only because it is not necessary at present. It should just help you to prioritise your work and prevent you from doing work that is based on assumptions. You’ll only risk having to re-do it later because the information you had earlier was wrong or not sufficient.When using YAGNI, you might get the impression that it will prevent you from doing experiments. This would be right if you ignored the YAGNI methodology while doing prototyping. It’s best to use the technique for focusing while you create a prototype. In that case it is totally OK to do the work twice. You can then learn from the feedback. After all, your prototype might not always be what the user or client expects, so you will need to discard your idea and re-do it. This is totally fine, and while implementing trials, you also should adopt YAGNI in order not to overload your outcome. Anyway, prototyping is about trying something while being aware that it may be dismissed in the end.<h2>Conclusion</h2>For me, YAGNI is an excellent way to improve your software development cycle. It helps you a lot to focus on necessary features and software pieces. You should use it for experiments (prototyping) and be aware that software pieces might have to be implemented multiple times. YAGNI and prototyping fit together perfectly. Now, go find something and simplify it down to essentials right now!

YAGNI – A quick introduction and field report

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/IStAzEB4R1mKwRHkdBqX"><img src="https://media.graphassets.com/IStAzEB4R1mKwRHkdBqX" 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/ai9qU79SShqHkJODAYIB"><img loading="lazy" src="https://media.graphassets.com/ai9qU79SShqHkJODAYIB" 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/nBsdt2CKTaugEPav2jx7"><img loading="lazy" src="https://media.graphassets.com/nBsdt2CKTaugEPav2jx7" 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/e0m2vVsRpm7JwKHyBrSw"><img loading="lazy" src="https://media.graphassets.com/e0m2vVsRpm7JwKHyBrSw" 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/DmyvaY7MSeUbmWwdKoK3"><img loading="lazy" src="https://media.graphassets.com/DmyvaY7MSeUbmWwdKoK3" 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/CG2UQ6nQnyZQkH1pFB4w"><img loading="lazy" src="https://media.graphassets.com/CG2UQ6nQnyZQkH1pFB4w" 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/DuweXxQduW8qtM8Yukzw" 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/uydRh5SZR3yPGmd2bK4M"><img loading="lazy" src="https://media.graphassets.com/uydRh5SZR3yPGmd2bK4M" 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/fKtb40bTIOMGAHY3x1Vj"><img loading="lazy" src="https://media.graphassets.com/fKtb40bTIOMGAHY3x1Vj" 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/mYat3uvTS7lsyLYq9INA"><img loading="lazy" src="https://media.graphassets.com/mYat3uvTS7lsyLYq9INA" 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/6GDWeccZRiq1Cc0vMH4N"><img loading="lazy" width="250" height="101" src="https://media.graphassets.com/6GDWeccZRiq1Cc0vMH4N" 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/RAGYBbtkSCiCaeFqzPsp"><img loading="lazy" width="250" height="100" src="https://media.graphassets.com/RAGYBbtkSCiCaeFqzPsp" 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/LxVateSEOpHjgdvdHkow"><img loading="lazy" width="250" height="115" src="https://media.graphassets.com/LxVateSEOpHjgdvdHkow" 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/czdEdbSNSSeqOmZFiPz7"><img loading="lazy" src="https://media.graphassets.com/czdEdbSNSSeqOmZFiPz7" 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

Sprich mich an

Möchtest du dich über KTOR austauschen?

Auf unserem Blog findest du viele Artikel zu Tech-Themen von unseren Mitarbeitenden. Vielleicht ist auch hier ein Thema für dich dabei. Schau gerne mal rein!

Hier gibt's noch mehr spannende Infos von uns für euch

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.

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

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.

Es gilt die Datenschutzerklärung der codecentric AG, abrufbar unter \nDatenschutzbestimmungen\n. Mit dem Absenden des Formulars bestätige ich, dass ich diese zur Kenntnis genommen habe.

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.

KTOR oder Spring Boot? Vergleich der Web-Frameworks

Aus dem Inhalt:

Sprich mich an

Hier gibt's noch mehr spannende Infos von uns für euch

Gemeinsam bessere Projekte umsetzen.

Wir helfen deinem Unternehmen.

Unsere Leistungen

Hilf uns, noch besser zu werden.

Zu den Jobangeboten