Konzepte wie Pair- und Mob-Programming werden in vielen Entwicklungsteams diskutiert, aber leider nur selten auch wirklich gelebt. Es gibt vielfältige Vorbehalte und Bedenken dagegen und der erhoffte Nutzen bleibt oftmals eher vage. Mit diesem Artikel soll ein nicht so offensichtlicher und damit auch oft unterschätzter Nutzen aufgezeigt werden, um so möglicherweise die Motivation für Pair- und Mob-Programming noch zu stärken.

Entwickler bekommen irgendwann einen Impuls zu Pair-Programming, z.B. durch einen Vortrag oder Artikel, und beschließen, das mal auszuprobieren. Die ersten Erlebnisse sind durchaus positiv, die Qualität des Ergebnisses ist höher, man hat anregende Diskussionen und kommt auf gute Lösungen, die einer allein nicht gefunden hätte. Danach wird Pair-Programming zwar gelegentlich angewandt, aber nicht systematisch und nicht oft genug, um es zur Routine werden zu lassen. Häufig schläft Pair-Programming dann wieder ein oder wird nur ganz selten genutzt, obwohl jeder es eigentlich gut findet. Schade, denn eigentlich passiert beim Pair-Programming im Verborgenen etwas, das ein Team erst wirklich erfolgreich werden lässt. Genau darauf soll der Fokus in diesem Artikel liegen.

Was ist Pair-Programming?

Der Einfachheit halber wird im Folgenden der Begriff Pair-Programming genutzt. Die beschriebenen Konzepte und Vorteile gelten gleichermaßen auch für Mob-Programming. Eine kurze Beschreibung zu Mob-Programming findet sich am Ende des Artikels.

Pair-Programming bedeutet, dass zwei Entwickler zur selben Zeit gemeinsam an einem Rechner eine Aufgabe erledigen. Dabei gibt es im Pair zwei Rollen:

• Der Driver bedient die Tastatur und Maus und versucht, die aktuelle Lösungsstrategie in funktionierenden Code zu überführen.
• Der Navigator betrachtet die aktuelle Aufgabenstellung aus einer stärker konzeptionell geprägten Perspektive und überprüft gleichzeitig die entstehende Lösung auf konzeptionelle Fehler. Diese werden dann sofort im Dialog zwischen den Pairing-Partnern gelöst. Zusätzlich hinterfragt der Navigator den einmal eingeschlagenen Lösungsweg immer wieder und überlegt, ob es bessere Alternativen gibt.

Dadurch kann das Pair auf zwei verschiedenen Abstraktionsebenen operieren, ohne dass die einzelnen Entwickler ständig den Kontext wechseln müssen. Diese Rollen sollten im Pair nach ca. 15-30 Minuten getauscht werden, um die Aufmerksamkeit hochzuhalten. Dafür wird oftmals eine Timebox genutzt, an deren Ende dann getauscht wird.

Was macht ein gutes Team aus?

Um nun näher auf den verborgenen Nutzen von Pair-Programming einzugehen, soll kurz betrachtet werden, was wichtige Aspekte eines guten Teams sind. Teams, die Verantwortung übernehmen, sind für jeden Chef ein Wunschbild. Noch besser, wenn alle gemeinsam diese Verantwortung übernehmen und automatisch jemand einspringt, sollte mal ein Teammitglied temporär ausfallen. Aus der Perspektive eines Teammitglieds fühlt es sich gut an, Teil einer Gemeinschaft zu sein, mit anderen gemeinsam auf ein Ziel hinzuarbeiten, an einem Strang zu ziehen und seine Stärken und Neigungen gewinnbringend für die Zielerreichung einbringen zu können.

Idealerweise agiert ein gutes Team folgendermaßen: Das Team entwickelt zunächst ein gemeinsames Problemverständnis. Auf Basis dieses Problemverständnisses können dann von verschiedenen Teammitgliedern aufgrund ihrer unterschiedlichen Erfahrungen und Kompetenzen Lösungswege vorschlagen werden. In einem konstruktiven Dialog wird aus den verschiedenen Lösungsoptionen eine gemeinsame Lösungsvision entwickelt, die das Team dann gemeinschaftlich umsetzt. Das Team erkennt selbstständig Informations- und Kompetenzlücken und reagiert entsprechend, um diese adäquat zu füllen. Für das Ergebnis fühlt sich jeder im Team verantwortlich, unabhängig davon, wer an der Umsetzung beteiligt ist. Dabei packt jeder eigenverantwortlich dort mit an, wo es notwendig ist. Das funktioniert umso erfolgreicher, je besser das Team eingespielt ist.

Wie entstehen nun solche Teams? Als größtes Hindernis für diese Zusammenarbeit, für die gemeinsame Verantwortung, stehen oftmals sog. Silos im Weg. Damit wird beschrieben, dass gewisse Kompetenzen und Fähigkeiten nur von einzelnen Mitarbeitern abgedeckt werden. Aus Effizienzgründen werden darum Aufgaben, in diesen Kompetenzbereichen genau von diesen Mitarbeitern abgearbeitet. Damit baut die umsetzende Person ihre Fähigkeiten in diesem Bereich weiter aus, der Rest des Teams wird aber weiter abgehängt und fühlt sich nicht in der Lage, zu diesem Thema aktiv beizutragen. Das führt dazu, dass die Zusammenarbeit reduziert wird, die Silos werden verstärkt. Diesen Teufelskreis zu durchbrechen ist eine große Herausforderung von vielen Teams und Organisationen. Und genau hier kann Pair-Programming helfen. Zunächst wollen wir uns aber dem Aufwand und dem offensichtlichen Nutzen von Pair-Programming zuwenden.

Aufwand für Pair-Programming

Als häufigstes Argument gegen Pair-Programming wird der zusätzliche zeitliche Aufwand genannt, schließlich arbeiten an der Aufgabe jetzt zwei Menschen. Einige Entwickler vertreten sogar den Standpunkt "Wenn ich es noch jemandem erklären muss, dauert es länger, als wenn ich es schnell alleine mache". Damit nehmen sie also nicht nur den doppelten Zeiteinsatz durch zwei Personen, sondern auch eine längere Dauer an. Befürworter von Pair-Programming behaupten wiederum, dass sie mithilfe von Pair-Programming viel schneller eine gute, nachhaltige Lösung erstellen können und so das Ergebnis nicht nur deutlich besser ist, sondern dabei auch noch Zeit gespart wurde. Die Bewertung des Aufwandes spielt dabei eine wesentlich wichtigere Rolle für die Akzeptanz, als die Einschätzung des Nutzens. Dieser ist schließlich viel unmittelbarer. Während ein großer Teil des Nutzens erst in der Zukunft realisiert wird (Weniger Fehler, die behoben werden müssen, bessere Wartbarkeit etc.), ist der Aufwand im Hier und Jetzt wirksam. Und vor allem wenn man das Gefühl hat, unter Lieferdruck zu stehen, wird dieser Aspekt eine entscheidende Rolle spielen. Für die Bewertung ist dabei entscheidend, wie diese Situation von den Teammitgliedern wahrgenommen wird und nicht unbedingt, was die Intention von Managern und Führungskräften ist.

Um also die Akzeptanz für Pair-Programming zu steigern, muss sehr genau darauf geachtet werden, wie der Aufwand empfunden wird und hier ggf. durch Experimente und konkrete Erfahrungen eine objektivere Beurteilung ermöglicht werden.

Der offensichtliche Nutzen von Pair-Programming

Dem gegenüber stehen verschiedene Vorteile, die sich durch Pair-Programming ergeben: an erster Stelle eine bessere Codequalität, die eine höhere Wartbarkeit verspricht, und eine höhere Ergebnisqualität. So entstehen im Pair oftmals einfachere, schnellere und weniger komplexe Lösungen, die anwendergerechter sind, und viele potenzielle Probleme sind bereits korrekt berücksichtigt. Damit erreichen wir einen reduzierten Aufwand für das Nacharbeiten, wie z.B. Codereviews, Refactoring oder auch Fehleranalyse und -behebung. Ein weiterer Nutzenbereich ist der Know-how-Transfer, der zwischen den Pairing-Partnern erfolgt. Man wird sich immer den ein oder anderen Trick abschauen können, oder auch neue Codekonstrukte lernen. Das Verständnis für unbekannte Codebereiche lässt sich am schnellsten durch gemeinsames Arbeiten im Pair entwickeln. Wenn ein Entwickler mit einem Tester im Pair arbeitet, werden beide gemeinsam aufgrund ihrer unterschiedlichen Perspektiven den effizientesten Lösungsweg und die ideale Teststrategie finden. Ob die Kosten-Nutzen-Betrachtung nun positiv oder negativ ausfällt, hängt von der jeweiligen Bewertung der Teilaspekte ab und hat damit einen wesentlichen Einfluss auf die Motivation, Pair-Programming im Alltag anzuwenden. Dabei wird allerdings ein "Kollateralnutzen" oftmals außen vorgelassen, der nicht so offensichtlich ist, aber die Kosten-Nutzen-Bilanz durchaus positiv beeinflusst.

Der verborgene Nutzen von Pair-Programming

Dieser verborgene Nutzen von Pair-Programming entsteht nicht direkt im Kontext der zu erledigenden Aufgabe. Vielmehr ist Pair-Programming - wenn es richtig genutzt wird - eine hervorragende Möglichkeit, um nicht nur Silos abzubauen, sondern auch um echte Zusammenarbeit und Kollaboration zu trainieren. Diese erwünschte Form der Teamzusammenarbeit ist in der Praxis gar nicht so einfach zu erreichen und stellt Teams teilweise vor neue Herausforderungen in Bezug auf Kommunikation und Konsensfindung. Arbeitet ein Pair gemeinsam an einer Aufgabe, dann ist eine Einigung auf eine gemeinsame Lösung unerlässlich. Gerade wenn es verschiedene Lösungsideen gibt, müssen Vor- und Nachteile zügig erfasst und abgewogen werden. Genau hier scheitern aber manche Teams bereits.

Wenn man es nicht gewohnt ist, seine Lösungsansätze zu artikulieren, entstehen schnell Missverständnisse oder man redet aneinander vorbei. Erntet man nicht umgehend Zustimmung, ist man verleitet, sich missverstanden zu fühlen und wiederholt deshalb nochmals seine Ausführungen. Oder man hat vermeintlich einen Konsens erreicht, jedoch stellt sich dann später heraus, dass das Verständnis davon doch noch recht unterschiedlich war. All diese Herausforderungen benötigen eine hohe Kommunikationskompetenz, die es einem Team erlaubt, in kurzer Zeit verschiedene Alternativen aufzubringen, abzuwägen, sich für eine zu entscheiden und diese dann mit vereinten Kräften umzusetzen. Genau das macht ein herausragendes Team aus. Und genau diese Kompetenzen werden beim Arbeiten in einem Pair geübt und trainiert. Zumindest dann, wenn Pair-Programming richtig gelebt wird, also wenn nicht nur ein Partner die Aufgabe erledigt und der andere das lediglich beobachtet. Nur dann, wenn der eingeschlagene Weg immer wieder hinterfragt wird, wenn nach möglichen Alternativen gesucht wird, entsteht im Pair eine produktive Spannung. Das funktioniert auch, wenn beide Partner unterschiedliche Wissens- und Erfahrungsstände haben. Allerdings ist hierzu auch eine gewisse Offenheit erforderlich. Die Offenheit, Impulse aufzunehmen und auch den eigenen Standpunkt für sich selbst zur Disposition zu stellen. Die Offenheit, in Widerspruch und anderen Ideen die Chance zu sehen, den eigenen Standpunkt weiterzuentwickeln, statt diesen zu verteidigen. Aber auch die Offenheit, zu erkennen, wie jeder im Pair seine eigene Perspektive und Erfahrungen einbringen kann, um von dieser Vielfalt und Breite zu profitieren. Mit dieser Offenheit kann man auch abseits der eigentlichen fachlichen Kompetenz voneinander profitieren.

• Wie geht der Partner bei der Fehleranalyse vor?
• Welche Quellen nutzt er für die Recherche und wie nutzt er diese?
• Wie betreibt jemand anderer Qualitätssicherung, auf welche Dinge wird dabei geachtet?

Pair-Programming ist ein methodischer Ansatz, mit dem wir neben der Stärkung technischer insbesondere auch die sozialen Kompetenzen im Team voranbringen.

Neben der persönlichen Wissensvermehrung entsteht auch eine gemeinsame Vorstellung im Team darüber, wie bestimmte Dinge am besten gelöst werden. Das Team wird genormt, und dieses Norming ist wiederum wichtig, um effizient diskutieren und arbeiten zu können. Eine gemeinsame Basis erlaubt es, dass sich Diskussionen um die wichtigen Aspekte drehen und nicht ständig über Grundsätzliches geredet wird. Mithilfe von Pair-Programming wird sehr schnell sichtbar, wo einzelne Teammitglieder unterschiedliche Stile und Vorlieben haben, und es kann nach einer Diskussion von verschiedenen Optionen und deren Vor- und Nachteilen ein gemeinsamer „Currently Best Approach“ festgelegt werden, ein Weg, den das Team gemeinsam als den richtigen empfindet, so lange, bis es neue Erfahrungen gesammelt und eine bessere Lösung gefunden hat. Im Pair entsteht dieses Alignment wesentlich schneller als durch unabhängige Entwicklung und nachgelagerte Codereviews. Die Pairing-Partner entwickeln darüber hinaus auch Empathie füreinander, ein gegenseitiges Verständnis für Meinungen, Bedenken und Motive. Mit gegenseitigem Respekt für die Position und Empfindungen des Gegenübers entsteht ein tiefes Vertrauen und ein Gemeinschaftsgefühl, das die optimale Basis für motiviertes Arbeiten ist. Besonders gut funktionierten dieses Norming und das gemeinsame Verständnis dann, wenn nicht nur diejenigen miteinander ein Pair bilden, die sich am besten verstehen und die großen Gemeinsamkeiten haben. Stattdessen sollen die Pairing-Partner immer wieder wechseln und somit Jede mit Jedem im Team zusammenarbeiten. Gerade mit den „Quertreibern“, mit denen, die uns und unseren Standpunkt nicht richtig verstehen, die unsere Überzeugungen augenscheinlich nicht teilen, sollten wir intensiver zusammenarbeiten. Das ist anstrengend, kann uns selbst und das gesamte Team allerdings entscheidend voranbringen.

Konkrete Tipps fürs Pair-Programming

Im Folgenden noch einige konkrete Tipps, wie man mit Pair-Programming schneller und besser an den Start kommen kann.

• Time Box für Rollenwechsel: Ein Rollenwechsel beim Pair-Programming ist immens wichtig, denn nur so lernen wir voneinander. Hat immer der die führende Rolle, der es am besten kann, wird der Zweite weniger Motivation empfinden, sich selbst aktiv zu beteiligen. Es geht ja eben nicht nur um die Vermittlung von fachlichem Wissen. Eine Time Box hilft dabei, den Wechsel wertfrei zu machen. Es übernimmt nicht derjenige die Umsetzung, der es am besten kann, sondern der, der an der Reihe ist. Dabei empfiehlt es sich, die Time Boxes sehr konsequent einzuhalten.
• Routine durch Übung: Pairing wird nur dann gut funktionieren, wenn alle im Team bereit sind, sich aktiv daran zu beteiligen. Damit der oben beschriebene Kollateralnutzen eintritt, muss es auch mit einer gewissen Häufigkeit geschehen. Pair-Programming nur dann einzusetzen, wenn es sich aufdrängt, kann zu wenig sein. Vielmehr sollte das Team sich darauf einigen, einen gewissen Anteil der Arbeit im Pair zu erledigen, um sich besser kennenzulernen und das Norming aktiv voranzutreiben. Dabei können sich selbst bei Aufgaben, für die ein Pairing ursprünglich nicht für sinnvoll erachtet wurde, durchaus positive Überraschungen ergeben.
• Mit Bedenken konstruktiv umgehen: Die Erwartung, dass jedes Teammitglied von Beginn Pair-Programming mit Begeisterung aufnimmt, ist wohl unrealistisch. Menschen sind geprägt durch Erfahrungen, die sie in der Vergangenheit gemacht haben. Diese können durchaus außerhalb des Teams sein und müssen nicht immer positiv gewesen sein. Deshalb ist es nicht verwunderlich, dass manche Menschen Pair-Programming eher negativ gegenüberstehen, weil sie sich da zu sehr kontrolliert fühlen, weil eigene Schwächen offenbart werden könnten oder weil man sich zu sehr unter Druck gesetzt fühlt. Diese Vorbehalte müssen ernst genommen und offen angesprochen werden. Nun aber diese Teammitglieder einfach vom Pair-Programming auszunehmen wäre der völlig falsche Weg. Statt dessen müssen diese Bedenken ergründet, Vertrauen aufgebaut und ein gemeinsamer Weg gefunden werden. Was würde dem Team-Kollegen denn helfen, damit er sich eher auf Pair-Programming einlassen kann?
• Infrastruktur/Set-up/Hardware: Auch nicht unterschätzt werden sollte die Auswahl der geeigneten Ausstattung und Hardware. Jeder Partner im Pair muss gleichberechtigt Zugriff auf die Inhalte haben. Sitzt ein Partner eher am Rand und muss den Hals verrenken, um am Bildschirm überhaupt etwas erkennen zu können, wird keine gleichberechtigte Zusammenarbeit entstehen.
• Remote Pairing: Mit modernen Kommunikationslösungen kann auch remote hervorragend gepairt werden. Im Grunde sind die Gegebenheiten dort sogar ideal. Es gibt Tools, die einen schnellen und reibungslosen Wechsel der Rollen ermöglichen, wie z.B. https://mob.sh/" oder auch https://code.visualstudio.com/learn/collaboration/live-share
• Organisatorischen Raum schaffen: Für Pairing müssen organisatorische Rahmenbedingungen geschaffen werden. Die wichtigste dabei ist, klar auszusprechen, dass ein solches Vorgehen erwünscht ist. Sowohl das Team als auch die Organisation sollten sich klar dazu bekennen, an die Vorteile von Pair-Programming zu glauben. Zumindest für eine Eingewöhnungszeit ist sollte dann die Kosten-Nutzen-Diskussion erledigt sein. Danach kann reflektiert werden, Vor- und Nachteile können transparent gemacht werden und das Team entscheidet, wie es weiter verfahren möchte.
• Retrospektive für die Pairing Session: Wie bereits zuvor ausgeführt, besteht ein großer Teil des Nutzens beim Pair-Programming darin, etwas zu lernen. Dabei hilft es, wenn sich am Ende einer Pairing Session die Partner gegenseitig fragen: „Was hast du in dieser Session gelernt? Was hat gut funktioniert? Was können wir beim nächsten Mal noch besser machen?“
• Genügend Pausen vorsehen: Pair-Programming ist anstrengend. Schließlich wäre es unhöflich dem Partner gegenüber, sich einfach mal für ein paar Minuten aus dem Geschehen auszuklinken, Mails und Social Media zu checken. Im Pair arbeiten die Partner üblicherweise über einen längeren Zeitraum voll fokussiert. Da ist es wichtig, ganz bewusst auch Pausen einzuplanen. Sehr gut eignet sich z.B. die sog. Pomodoro-Technik https://de.wikipedia.org/wiki/Pomodoro-Technik
• Onboarding neuer Teammitglieder: Ohne Unterstützung hat es ein Neuankömmling in einem Team sehr schwer. Häufig wird die Einarbeitungsdauer neuer Kollegen von den Teams auf mehrere Monate eingeschätzt. Das hängt damit zusammen, dass Entwickler erst ein gutes Verständnis der bestehenden Codebasis und der Anwendungsdomäne brauchen, bevor sie etwas Sinnvolles beitragen können. Im Pair mit einem erfahrenen Kollegen kann ein Neuling allerdings bereits sehr früh einen Beitrag leisten, ohne das Risiko für Fehler zu erhöhen. Arbeitet das neue Teammitglied jeden Tag mit einem neuen Partner im Pair, entsteht sehr schnell ein guter Gesamtüberblick.

Was ist Mob-Programming?

Mob Programming ist gewissermaßen die Fortführung von Pair-Programming. Dabei werden Aufgaben gemeinsam in einer Gruppe (dem Mob), z.B. dem gesamten Team, an einem einzigen Rechner bearbeitet. Dafür ist ein großer Bildschirm oder ein Beamer erforderlich, damit alle Beteiligten das aktuelle Geschehen verfolgen und darauf Einfluss nehmen können. Idealerweise ist auch der Anforderungsverantwortliche (z.B. Product Owner) aktiv beteiligt und kann so direkt Fragen zur Anforderung klären und das entstehende Ergebnis aus seiner Perspektive mit beeinflussen. Auch remote kann Mob-Programming sehr gut funktionieren. Es gibt Teams, die dies als ihren Standardarbeitsmodus definiert haben und berichten, dass sie noch nie so schnell und effizient zu Lösungen gekommen sind. Mob-Programming ist auch aus einer Flow-Sicht ideal. Die Umsetzung einer Aufgabe wird begonnen und da alle benötigten Personen direkt im Mob beteiligt sind, kann diese ohne Unterbrechungen und Wartezeiten in einem Rutsch abgeschlossen werden. Siehe auch https://www.youtube.com/watch?v=28S4CVkYhWA Aber selbst wenn Teams Mob-Programming nur punktuell einsetzen, ist es eine extrem effiziente Möglichkeit, das Team-Norming und ein Gemeinschaftsgefühl zu entwickeln.

Pair Writing

Dieser Artikel ist auch im Pair entstanden. Die Autoren haben sich bewusst dafür entschieden, dieselben Konzepte einzusetzen wie beim Pair-Programming. Üblicherweise hätten wir uns für eine grobe Struktur entschieden, den Artikel inhaltlich dann aufgeteilt und jeder hätte seinen Teil erstellt, der vom jeweils anderen gereviewed worden wäre. Stattdessen haben wir den Artikel komplett im Pair erstellt, also zwei Personen, eine Aufgabe, ein Rechner. Obwohl es im Vorfeld eine gesunde Portion Skepsis gab, ob sich eine solche Aufgabe überhaupt zum Pairing eignet, waren die Erfahrungen damit überaus positiv. Erwartet wurde, dass jeder besser für sich seine Gedanken ordnen und in Worte fassen sollte. Tatsächlich haben sich aber an unterschiedlichen Formulierungen und thematischen Schwerpunkten überaus spannende Diskussionen ergeben, die nicht nur zu einem wesentlich tieferen gemeinsamen Verständnis des Themas, sondern auch zu größerer Empathie zwischen den beiden Autoren geführt haben. Nach dieser Erfahrung gehen wir davon aus, dass es nur wenige Aufgabenstellungen gibt, bei denen Pair-Working gar keinen Sinn macht, es ist lediglich eine Frage des Willens und der Offenheit für den positiven Kollateralnutzen.

Fazit

Wer noch das Image des Softwareentwicklers als einsamer, kontaktscheuer Nerd pflegt, der wird sicher den Vorteilen des Pair-Programmings eher skeptisch gegenüberstehen. Wer glaubt, dass er selbst die beste Lösung findet, wenn man ihn nur in Ruhe arbeiten lässt, der wird das Zusammenarbeiten im Pair eher als ein Ausbremsen, denn als persönliche Bereicherung ansehen.

Wer aber an echte Teamarbeit glaubt, wer Spaß daran hat, mit anderen gemeinsam etwas zu erreichen, wer die Geborgenheit der Gruppe schätzt und auch bereit ist, sich am Arbeitsplatz darauf einzulassen, der braucht das richtige Team um sich herum. Teamarbeit wird zwar in sehr vielen Jobanzeigen versprochen, doch wird der Begriff sehr unterschiedlich interpretiert. Wenn eine Gruppe von Personen zusammen an etwas arbeitet, wird das schon als Team bezeichnet. Mit einer echten Teamarbeit mit Vertrauen, Empathie und gemeinsamen Zielen, hat das aber oft nicht viel zu tun. Geschenkt bekommen wir ein solches Team nicht, es wird nicht von allein entstehen. Jeder hat die Möglichkeit, sein Team und somit sein Arbeitsumfeld mitzuprägen. Die meisten Teams haben ausreichend Gestaltungsspielraum, diesen Ansatz zu nutzen, um zunächst erste Erfolge unter Beweis zu stellen und damit für mehr zu werben. Pair-Programming ist ein methodischer Ansatz, mit dem wir neben der Stärkung technischer, insbesondere auch die sozialen Kompetenzen im Team voranbringen. Frei nach dem Motto: Pfeif auf die Weihnachtsfeier und den Hochseilgarten - es lebe der Alltag!

Autoren:

Thomas Schissler ist Gründer von agileMax, einem agilen Beratungsunternehmen. Er unterstützt als Coach und Consultant Kunden bei der Verbesserung ihrer Softwareentwicklungsprozesse auf Basis von Agilität. Als Trainer bietet Thomas hauptsächlich die Scrum-Trainings der scrum.org an, aber auch technische Trainings oder Workshops zum Thema DevOps, Teststrategien oder Refactoring. Seit 2008 ist er jährlich von Microsoft mit dem Microsoft MVP Award im Bereich Developer Technologies ausgezeichnet worden. Sein Steckenpferd ist aktuell das Thema DevOps, das neben den organisatorischen Herausforderungen vor allem auch auf technischer Ebene spannend ist und damit die beiden Interessensgebiete von Thomas ideal vereint.

Thomas Trotzki ist Microsoft-C++- und -.NET-Profi der ersten Stunde. Neben seinem tiefen technologischen Verständnis ist er seit nunmehr über fünfundzwanzig Jahren mit der Organisiation von Softwareprojekten vertraut und hat umfangreiche Expertise im Bereich Application Lifecycle Management. Er betreut und unterstützt Unternehmen hinsichtlich der Verbesserung von Softwareentwicklungprozessen und des Einsatzes aktueller Softwaretechnologien. Persönlich beschäftigt er sich viel mit dem Thema „Beyond Agile and DevOps“: Welche Probleme sind in der Softwareentwicklung eigentlich zu lösen, und weshalb tragen agile Ansätze immer mehr zu deren Lösung bei?