Continuous Lifecycle/ContainerConf 2024

Unsere Speaker*innen halten spannende Vorträge rund um Developer Experience, Platform Engineering und noch vieles mehr. Seid dabei!

IT Consultant

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

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

<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/AKimbKMiTDSNSzrjDRpe"><img src="https://media.graphassets.com/AKimbKMiTDSNSzrjDRpe" 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/v9l8y657R6YxUNn2Ba3e"><img loading="lazy" src="https://media.graphassets.com/v9l8y657R6YxUNn2Ba3e" 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/KYi4gEHmQN2WTxjKc6aV"><img loading="lazy" src="https://media.graphassets.com/KYi4gEHmQN2WTxjKc6aV" 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/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

Software Team Enabler

Talk "Der KI-gestützte Entwickler"

OpenAPI-Spezifikationen (OAS) beschreiben standardisiert und Programmiersprachen-unabhängig HTTP-APIs. Für die Erstellung von OAS gibt es verschiedene Möglichkeiten, häufig werden sie auch generiert. Das ist aber nicht für alle Programmiersprachen und Systeme möglich. Darum gibt es Editoren wie den Swagger-Editor und Stoplight Studio, die das Schreiben und Bearbeiten von OAS unterstützen. Aber geht das auch in der alltäglich verwendeten IDE?\nDieser Artikel evaluiert VS Code als alternativen Editor für OAS, vergleicht verschiedene Erweiterungen zu diesem Zweck und stellt exotische Ideen, interessante Features, Lücken und Bugs aus der breiten Palette der VS-Code-Erweiterungen vor.\nInsgesamt wurden 15 VS-Code-Erweiterungen für \nOpenAPI\n untersucht. Dabei wurden sieben Erweiterungen nach einem kurzen Test aufgrund von größeren Bugs und Fehlern verworfen und die verbliebenen Erweiterungen hinsichtlich folgender Merkmale verglichen:\nUmfang\n: Welche OpenAPI-Versionen werden unterstützt? Welche Dateitypen (YAML/JSON) werden unterstützt?\nLint\n: Warnungen und Fehler in Syntax und Struktur der OAS werden erkannt, markiert und erklärt.\nAuto-Vervollständigung\n: Ein Autovervollständigungs-Feature gibt Vorschläge zur Vervollständigung der Zeile, wenn der Entwickler zu tippen beginnt und es gibt Vorschläge zu möglichen Schlüsselwörtern und Werten, bevor der Entwickler zu tippen beginnt.\nPreview\n: Eine Vorschau der resultierenden Dokumentation der API kann generiert werden.\nTemplate\n: Es wird eine einfache OAS als Beispiel für OpenAPI-Newbies oder als Quickstart-Template bereitgestellt.\nTemplate-Snippets\n: Die Erweiterung erstellt YAML/JSON-Snippets für die einzelnen Abschnitte und Elemente der OAS. Die Entwickler müssen sich so nicht genau an die Struktur der OAS erinnern, sondern können einfach das vorgefertigte Snippet-Template ausfüllen.\nInline-Dokumentation und Erklärungen\n: Es werden Erklärungen zur Bedeutung der verschiedenen Abschnitte und Schlüsselwörter der OAS bereitgestellt.\nVisualisierung\n: Die OAS kann visualisiert werden, zum Beispiel als Übersichtsgrafik.\nDazu wurden folgende OAS  zum Testen verwendet:\n\nOpenAPI v2.0/Petstore\n: Ein einfaches Beispiel mit rund 150 Zeilen\n\nOpenAPI v3.0/Petstore\n: Ein einfaches Beispiel mit rund 150 Zeilen\n\nOpenAPI v3.0/Swagger-Petstore\n: Ein ausführlicheres Beispiel mit rund 800 Zeilen und  mehreren verschiedenen Operationen\nVergleich der OpenAPI-VS-Code-Erweiterungen\nDie Übersicht der Funktionalitäten der verschiedenen Erweiterungen sind in der Tabelle unten zusammengefasst. Dabei sind die VS-Code-Erweiterungen sortiert nach Popularität (gemessen an der Anzahl der Downloads).\n\n\nEs gibt nur zwei Erweiterungen, die viele Funktionen integriert haben. Das sind die Erweiterungen \nOpenAPI (Swagger) Editor\n und \nRedocly OpenAPI\n. Die anderen Erweiterungen haben sich auf eine Funktion spezialisiert, wie Preview oder Linting. Meistens werden die OpenAPI-Versionen v2.0 und v3.0 sowie beide Dateitypen (JSON und YAML) unterstützt. \nHighlights\nEine Liste an Funktionalitäten allein kann das Verhalten einer Erweiterung nicht vollständig beschreiben. Daher stellt dieser Artikel im Folgenden interessante und inspirierende Features vor, die bei der Recherche aufgefallen sind. \nOpenAPI v3.0/Swagger-Petstore: Die Erweiterung für alles mit interaktiver Übersicht\nDie Erweiterung \nOpenAPI (Swagger) Editor\n enthält alle Basics (Linting, Intellisense, Dokumentation-Preview) zu einem gewissen funktionellen Grad und unterstützt auch Snippet-Generierung. Ein Highlight ist die einfache, navigierbare Übersicht über die OAS in der Seitenleiste. Über diese bekommt man nicht nur eine Zusammenfassung der OAS, sondern kann auch im Code zu der gewünschten Stelle springen.\nSeitenleiste zur Übersicht und Navigation\nSo sieht die Übersicht über die ausführliche \nOpenAPI v3.0/Swagger-Petstore\n OAS aus. Die einzelnen Elemente kann man aufklappen und den Inhalt einsehen.\n\nBei einem Mausklick auf ein Element der Übersicht springt man automatisch zu dem dazugehörigen Code-Abschnitt. Die Seitenleiste dient also zusätzlich zur Navigation.\nRedocly OpenAPI: Cursor-Kontext und Formulare\nDie Erweiterung \nRedocly OpenAPI\n ist vielseitig und stellt Validierung, Auto-Completion und eine Preview-Dokumentation bereit (die man allerdings ohne Redocly-Account nicht öffnen kann). Besonders interessant sind jedoch die interaktiven Formulare und Kontext-bewussten Hilfetexte, die die VS-Code-Erweiterung im sogenannten Cursor-Kontext bereitstellt.\nDer Cursor-Context öffnet sich per default in der Übersicht, dem „Root“-Verzeichnis der OAS. Zu jedem Abschnitt, jedem Unterabschnitt und vielen weiteren Schlüsselwörtern werden im Cursor-Kontext Erklärungstexte bereitgestellt.\n\nFolgt man dem Navigationslink zum Beispiel zum Info-Abschnitt, springt man im Code zu der richtigen Stelle und kann auch im Cursor-Kontext den Abschnitt mittels interaktiver Formulare bearbeiten. \n\nLeider sind für viele der im „Root“ verlinkten Abschnitte keine Formulare vorhanden. Zum Beispiel beim Server-Abschnitt wird man darauf vertröstet, dass der Abschnitt bald implementiert werden wird.\n\nAllerdings sind bei einer anderen Cursor-Position Formulare vorhanden: \n\nDieses Phänomen der schlecht verlinkten Formulare ist mehrfach zu finden (zum Beispiel auch für die Tags), allerdings gibt es auch leider Abschnitte, für die tatsächlich keine Formulare zu existieren scheinen. Manchmal bilden die Formulare auch einfach nicht den notwendigen Funktionsumfang des OAS-Abschnitts ab. Nichtsdestotrotz bietet die Redocly-Erweiterung für OpenAPI-Anfänger eine starke Unterstützung.\nPreview für Swagger UI und ReDoc\nAlle Erweiterungen, die überprüft wurden, haben für den Preview der Dokumentation entweder die Swagger UI (die UI des populären \nSwagger Editor\ns) oder die ReDoc (von Redocly) in VS Code integriert. Dabei ist auch die Funktion enthalten, mit der Beispiel-Requests für einen Endpunkt automatisch generiert werden.\nBeide Preview-Typen sind im \nOpenAPI (Swagger) Editor\n integriert. \nWer nur den Swagger UI Preview nutzen möchte, kann auch die Erweiterung \nV-Swagger\n \nnutzen. Dieser enthält keine anderen Funktionalitäten (Linting, etc.) sondern wirklich nur den Preview.\nWer nur den ReDoc Preview haben möchte, kann auch die Erweiterung \nReDoc Viewer\n nutzen.\nOpenapi-lint: OAS konvertieren und bündeln\nDie Erweiterung \nopenapi-lint\n kann zwischen den OpenAPI Versionen 2.0 und 3.0 und zwischen den YAML- und JSON-Dateiformaten konvertieren. Außerdem kann sie das „Bundling“ übernehmen. Bundling führt mehrere OpenAPI-Dateien zu einer Datei zusammen, wobei externe Referenzen zu lokalen Referenzen aufgelöst werden. Alle entstehenden Dateien werden in einem neuen Fenster geöffnet, sodass die alte Datei nicht überschrieben wird.\nOAS2Tree: Eine Baum-Visualisierung der Pfadstruktur\nInteressant, aber leider hat OAS2Tree in VSCode nicht funktioniert.\n\n\nOAS2Tree\n transformiert eine OAS zu einer Baum-Visualisierung. Die Knoten des Baums sind interaktiv, geben Detailinformationen und lassen sich aufklappen und zusammenfassen. Allerdings sind sie nicht mit dem entsprechenden Code-Abschnitt im OpenAPI-File verlinkt.\nLeider hat die VS-Code-Erweiterung von OAS2Tree nicht funktioniert. Beim Öffnen der Live-Visualisierung kam unabhängig von der gewählten OAS stets dieselbe Fehlermeldung: \nTopology is closed\n.\nDie \nWeb-Version von OAS2Tree\n funktioniert jedoch wunderbar. Die Baum-Visualisierung bildet dabei den \nPaths\n-Abschnitt der OAS ab. Dieser definiert die Endpunkte der API und die darauf verfügbaren HTTP-Methoden.\n\n\n\nDie Baum-Visualisierung des Beispiels \nOpenAPI v3.0/Petstore\n in der Web-Version von  OAS2Tree.\nDer Root-Knoten \n/\n wird durch den Endpunkt \n/pets\n erweitert. \n/pets\n wird durch den Unterpfad \n/pets/{id}\n erweitert. Jeder Endpunkt wird durch die auf ihm verfügbaren HTTP Methoden erweitert. \nGET\n wird dabei als grüner Knoten dargestellt, \nPOST\n als gelber Knoten und \nDELETE\n als roter Knoten.\n\nWenn man mit der Maus über einen Knoten hovert, lässt sich der vollständige Pfad ablesen.\n\nAuf die HTTP-Methoden folgen zwei Typen von Blattknoten. Sie lassen sich mit einem Mausklick aufklappen.\n(?)\n: Die Parameter der Methode. In dem obigen Beispiel gibt es den Parameter \ntags\n vom Datentyp \narray\n und den Parameter \nlimit\n vom Typ \ninteger\n.\n(>)\n Die \nresponses\n (HTTP-Antworten) der Methode. Im Beispiel gibt es die HTTP-Antwort \n200 OK\n und die \ndefault\n Antwort-Spezifikation, welche das Verhalten für alle möglichen HTTP-Antworten außer \n200 OK\n zusammenfasst.\n\n\nDer Baum für die \nausführliche Swagger-Petstore OpenAPI v3.0 Spezifikation\n. Bei zunehmender Größe der OAS wird der Baum allerdings schnell groß und etwas unübersichtlich.\nFazit\nJa, man kann definitiv OAS-Dateien in VS Code schreiben! Die Erweiterungen enthalten einen bunten Blumenstrauß an Funktionalitäten und die meisten sind auch sehr zuverlässig in dem, was sie tun. In einigen Erweiterungen ließen sich aber auch einige Bugs und Lücken finden. Es wäre großartig, wenn diese bald gefixt werden, sodass auch diese guten Ideen so viel genutzt werden, wie sie es verdienen. \nAlles in allem können aufgrund der vorangegangenen Recherche folgende Setups für OpenAPI in VSCode empfohlen werden:\nEmpfehlenswert ist, die Erweiterung OpenAPI (Swagger) Editor in Kombination mit einer Linting-Erweiterung wie zum Beispiel Spectral zu nutzen. Der OpenAPI (Swagger) Editor kann nämlich zwar fast alles gut, aber sein Linting ist nicht ausreichend. Mit diesem Setup werden die OpenAPI-Versionen v2.0-v3.0 und beide Dateitypen unterstützt.\nAlternativ kann man Redocly OpenAPI nutzen. Dieses bietet mehr Unterstützung für Anfänger mit OpenAPI. Allerdings ist die Erweiterung gerade in den interaktiven Formularen, die für Anfänger besonders attraktiv sein können, lückenhaft und etwas verbuggt. Zudem muss man Redocly OpenAPI mit einer Preview-Erweiterung nutzen, wenn man keinen Redocly Account anlegen möchte. Mit diesem Setup werden die OpenAPI-Versionen v2.0-v3.1 unterstützt. Als Dateityp kann nur YAML verwendet werden.

OpenAPI direkt in VS Code schreiben – geht das?

Renovate in Azure DevOps Pipelines with Presets and Custom Managers

Werkstudentin

3 Steps to Access AWS Resources with Google Sign-In

How to create an AWS Lambda Authorizer for an Amazon API Gateway

*An Enabling Team is one of the four team types of the Team Topologies framework, as introduced by Matthew Skelton and Manuel Pais. How can this pattern be successfully applied to the design and development of APIs to create interfaces that really contribute to the business strategy?*

APIs are an important building block for digitalization and thus, the pressure on development teams to provide APIs is constantly growing. However, development teams often lack the necessary knowledge and experience, especially when they are mainly working in the ERP environment or in backend systems. Combined with pressing deadlines, this leads to APIs that are non-reusable, difficult to maintain, insecure and poorly documented. This frustrates and significantly slows down the development teams that rely on APIs and therefore has a negative impact on an organisation's ability to innovate. An API Enabling Team made up of experts can help teams to get started to ensure that high-quality APIs are created which contribute to the business strategy and promote the success of the organisation. This article highlights the challenges, foundations, prerequisites and opportunities of API enabling as an important success factor for establishing APIs as building blocks for digitalization.

## Challenges
Why do many development teams struggle to build high-quality APIs? Development teams that mainly work with legacy systems or have very specialised skills lack the necessary knowledge. Many practices of modern software development have not yet reached them, but these are essential for the development of high-quality APIs. 

In huge organisations, a large number of teams and different services have to be involved for the provisioning of interfaces. This includes teams who are responsible for integration, middleware (such as API management) or authorisation. This is particularly difficult to navigate for beginners, but it also puts experienced development teams to the test. 

In addition, requirements are often ‘thrown over the wall’ to the development teams. As a result, they have very little knowledge of the stakeholders of their APIs and therefore cannot identify with them or understand what they need to deliver to satisfy their stakeholders. The users of the API are thus not perceived as customers, but as someone who creates additional work for the team, namely the development of an API, which is not one of the team's core tasks and poses major challenges.

## Team Topologies as Foundation
The Team Topologies framework provides the basis for efficient software development. It distinguishes between four different types of teams: Stream-Aligned (business-oriented), Enabling (supporting), Complicated Subsystem (specialised) and Platform (accelerating). The teams interact using three different interaction patterns, either collaboratively, as-a-service or through facilitation. Exemplary interaction between the team types of the Team Topologies framework: 

<img src="https://media.graphassets.com/Pug7EuqDTdaSn5j1CHUQ" width="700" alt="Exemplary interaction between the team types of the Team Topologies framework" />

*Image taken from the book Team Topologies by Matthew Skelton and Manuel Pais, 2019. Used with permission.*

An Enabling Team consists of experts who impart knowledge and expand the skillset of the stream-aligned teams by taking over the evaluation and testing of new tools, methods, frameworks and the like. They only support stream-aligned teams for a certain period of time and not permanently.

This article sheds light on the extent to which an Enabling Team specialised on APIs (hereinafter referred to as an API Enabling Team) can support Stream-Aligned Teams in broadening their skillset to make them fit for API design and implementation.

## Tasks of an Enabling Team for APIs
The primary task of an API Enabling Team is to support other teams and train them with regard to APIs. To do this, the team must develop a workshop concept that takes into account both modern standards as well as the organisation’s circumstances and API strategy. At best, the team supports the Stream-Aligned Teams during the design and development of their first API. It is important that the Enabling Team only provides support and does not develop the API itself. As the API Enabling Team cannot be familiar with every backend technology in the organisation, the Stream-Aligned Teams must be sufficiently familiar with their technology. Once the Enabling Team has provided support, it provides documentation that enables the Stream-Aligned Teams to go through the same process independently the next time. Of course, it will also remain available in the future for special questions, reviews and the like.

An API Enabling Team is most effective when it is also involved in high-level topics and can influence the API strategy, governance and operations so that the experiences with the individual teams can be taken into account and, ideally, incorporated there.

An API Enabling Team also helps to build a vibrant API community, as it establishes the necessary contacts with the individual development teams and can thus connect them with each other.

## Following a Philosophy
To be successful as an API Enabling Team, the team must be guided by the organisation's enterprise architecture and API strategy and derive its philosophy from these.

Based on the organisation's enterprise architecture, the API Enabling Team derives a golden path and identifies the procedures and tools that must be observed and used by the Stream-Aligned Teams. These can be, for example, certain architecture patterns, a prescribed API management tool or prescribed quality features.

Based on the organisation's API strategy, the Enabling Team supplements its philosophy with specific API topics. The main focus here is on aspects such as reusability, APIs as a product, user-centred development and API design first vs. code first.

It is important that the API Enabling Team makes its philosophy transparent and bases all its actions and workshops on it.

## Developing a workshop concept based on the philosophy
Based on its philosophy derived from the organisation, the API Enabling Team then develops a tailor-made workshop concept:

<img src="https://media.graphassets.com/fECA7aLLR3qUjlmNosuU" width="500" alt="How to derive a workshop concept" />

The workshop concept consists of individual building blocks and must take into account the different levels of knowledge of different Stream-Aligned Teams. The following topics should at least be covered by the workshop concept: 
* Basic functionality of an API
* User-centred API development and stakeholder involvement, including developer experience
* Various interaction patterns and their areas of application
* Creation of a data model
* API design & standard formats (e.g. OpenAPI)
* API guidelines, standards and helpful tools in the organisation and beyond
* API management in connection with the topics of security and authentication/authorisation
* Backend development (as far as possible)
* Testing

The development of such a comprehensive workshop concept requires time and expertise. Further development and improvement of the concept based on experience with the Stream-Aligned Teams is essential.

## Implementing the workshop concept
To test the workshop concept, the API Enabling Team first approaches selected Stream-Aligned Teams that are open to new ideas and direct dialogue. After trialling, all Stream-Aligned Teams are given the opportunity to make use of the API Enabling Team to develop their first high-quality API. Firstly, the API Enabling Team always clarifies the requirements and expectations with the respective Stream-Aligned Team and makes its philosophy transparent. It must then clarify that APIs are the right technical solution for the tasks of the Stream-Aligned Team. It often turns out that this is not the case at all. However, if this is the case, the necessary workshops and work sessions can then be planned together in the way that best suits the Stream-Aligned Team's day-to-day work. Once the workshops have been held, the Enabling Team systematically collects feedback and integrates the Stream-Aligned Team into an API community, where team members can share problems, challenges and successes with other development teams. 
It is important that no Stream-Aligned team is forced into enabling if it does not want to. However, experience shows that good enabling is spread by word of mouth among teams. This automatically increases the demand for enabling.

## Platform Aspects
In order to work effectively and efficiently as an API Enabling Team, the general process of how APIs are created in the organisation must be as lean and clear as possible. The team must be enabled to improve the process together with other teams. It is also a good idea to establish an API Platform Team if many parts of the existing process are not yet automated. Automated API operations support the Enabling Team in transferring knowledge more quickly and making the existing services known to the Stream-Aligned Teams rather than reinventing the wheel for each individual Stream-Aligned Team. At the same time, the offered services help to reduce the cognitive load for the Stream-Aligned Teams, who already have to learn a lot of new things during the enabling process.

## Prerequisites for success
In order for the introduction of an API Enabling Team to be successful, a number of prerequisites must be met. Firstly, it is important that the team has the support of management. As the Enabling Team itself does not write any software and therefore does not deliver any demonstrable products, management must be convinced of its importance and also use the right metrics for evaluation. The number of APIs created, for example, which is often used as a metric, is only meaningful to a limited extent, as it neither says anything about the quality of the APIs nor takes into account teams for which an API was not a sensible solution.

A successful API Enabling Team also works with many other teams, mainly Platform, Complicated Subsystem and other Enabling Teams (e.g. authorisation teams, integration teams, etc.). These teams must be prepared to exchange the necessary information with the API Enabling Team which they share with the Stream-Aligned Teams in a condensed and processed form.

Another important prerequisite for the success of an API Enabling Team is to motivate the Stream-Aligned Teams to collaborate with them. This is difficult to achieve if the costs for the Enabling Team are passed on internally to the Stream-Aligned Teams. The enabling should be free of charge for all teams and it should be as simple as possible to make use of it.

## Conclusion
An API Enabling Team, based on the team types introduced in Team Topologies, successfully supports Stream-Aligned Teams in publishing their first API following a well-established approach. An organisation that relies on an API Enabling Team can ensure that high-quality APIs are created, which contribute to the business strategy and success of the organisation. The Enabling Team achieves this through a customised workshop concept, which ensures that Stream-Aligned Teams learn and master all important tasks related to the creation, development and publication of APIs.

The success of an API Enabling Team is closely linked to the support of management, the willingness of other central teams to work together and the motivation of the Stream-Aligned Teams. It is only when these requirements are met that the API Enabling Team can become a critical factor in the success of your business.

Charge your APIs Volume 29: API enabling as a factor for success

Lead API Consultant

Talk "Eine Pipeline als Produkt denken: Modularisierung, Versionierung, Testen, ..."

Weitere Infos

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

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?  

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.

Continuous Lifecycle/ContainerConf 2024

Weitere Infos

Talk "Der KI-gestützte Entwickler"

Talk "Eine Pipeline als Produkt denken: Modularisierung, Versionierung, Testen, ..."

Gemeinsam bessere Projekte umsetzen.

Wir helfen deinem Unternehmen.

Unsere Leistungen

Hilf uns, noch besser zu werden.

Zu den Jobangeboten