Thomas Much

Information & Communications Technology

Modern Agile Pair Programming Mob Programming Coaching Java Java EE Enterprise Java / Jakarta EE Monoliths Microservices Software Architecture Continuous Software Development

Hamburg, Germany

Thomas Much

Freelancer

As a technical agile coach and software developer, Thomas helps numerous teams to master their methodical and technical challenges. He’s working in projects from enterprise monoliths to e-commerce microservices, most of the time using the Java stack.

Thomas Much

Freiberufler

Als technischer agiler Coach und Softwareentwickler (Java et al.) unterstützt Thomas Much zahlreiche Teams bei der Bewältigung der alltäglichen Projekt-Herausforderungen, sowohl methodisch als auch technisch - und oft auch an der Reibefläche dazwischen. Er lebt mit seiner Familie in Hamburg und lässt sich gerne vom nordischen Wind den Kopf für neue Ideen freipusten.

Current sessions

Team-Entscheidungen klappen nicht? Mit Mob-Programming doch!

Wir wissen alle, wie Teams normalerweise Entscheidungen gemeinsam treffen: Nur sehr zögerlich oder gar nicht. Daher werden oftmals fertige Entscheidungen zur Umsetzung ins Team gegeben. Oder Einzelne treffen die Entscheidungen und wundern sich dann, dass der Rückhalt vom restlichen Team fehlt. Dabei wäre es für agile Organisationen am besten, wenn Entscheidungen dort getroffen werden, wo Wissen, Erfahrung und Können zusammentreffen. Also im umsetzenden Team zusammen mit den fachlichen Experten.

In den vergangenen vier Jahren konnte ich als Coach und auch als Entwickler erleben, wie zögerliche, dysfunktionale Teams innerhalb weniger Mob-Programming-Sessions durch Erfolgserlebnisse plötzlich Vertrauen in sich fanden und durch das gemeinsame Planen und Umsetzen von Aufgaben die nötigen Entscheidungen quasi nebenbei getroffen haben. Das hatte nachhaltige, positive Auswirkungen auf das Team-Selbstvertrauen und dadurch auf die Art und Weise, wie danach gemeinsam gearbeitet und Entscheidungen getroffen wurden.

In diesem Vortrag möchte ich berichten, wie die Entscheidungsfindung beim Mob-Programming funktioniert. Auch als Entscheidungshilfe für Management und Teamleitung, warum man seinen Teams den Rückhalt (und die Zeit) geben sollte, Mob-Programming auszuprobieren.


Mob-Programming. Zusammen lernen. Zusammen liefern!

Wenn man die Ideen von Lean, Agile, XP etc. ernst nimmt, müsste man alles daran setzen, seine Aufgaben zu priorisieren und die wichtigste Aufgabe möglichst zügig und gut zum Kunden auszuliefern. Leider sieht die Realität oft anders aus: Die individuelle Auslastung wird maximiert, die Entwickler arbeiten an vielen Aufgaben gleichzeitig. Die Features landen halbgar beim Kunden, die Entwickler müssen ständig Bugs fixen und für fachliche Weiterentwicklung fehlt leider die Zeit.

Als Lösung dieses Problems setzen wir auf Team-Building, arbeiten an der Kommunikation, machen Pair Programming, suchen Collective Code Ownership. In Zeiten von zunehmend komplexen Problemen ist das vielleicht nicht mehr genug - weil die Teams nicht nur das Ergebnis gemeinsam verstehen müssen, sondern auch den Weg der Problemlösung.

Vor einigen Jahren kam die Idee auf, Softwareentwicklung wirklich durch das gesamte Team durchführen zu lassen - und zwar zusammen, Aufgabe für Aufgabe. "Mob Programming" war geboren. Die Blockaden während der Entwicklung verschwinden, weil sich alle nötigen technischen und fachlichen Ansprechpartner im selben Raum befinden. Klingt verrückt? Funktioniert aber!

In diesem Talk werde ich die Grundlagen von Mob Programming vorstellen, die Gemeinsamkeiten und Unterschiede zum Pair Programming und wann sich das Arbeiten als "Mob" lohnt. Dazu gibt es Tipps aus der Praxis.


Agile ist tot. Lang lebe Modern Agile!

Agile ist erwachsen geworden: Vor über 18 Jahren wurde das Manifest für Agile Softwareentwicklung veröffentlicht. Mittlerweile ist Agilität im Mainstream angekommen. Doch oft fühlt sich das nicht besser an - es geht wieder um Prozesse, Geschwindigkeit und Kontrolle. Dabei wollte das Agile Manifest doch etwas ganz anderes.

Die Prinzipien und Werte, die hinter erfolgreicher Agilität stecken, sind so wichtig wie nie zuvor. Kunden erwarten zügig neue Features, die sie von der Konkurrenz kennen. Gleichzeitig muss die Qualität stimmen. Entwickler findet man nicht mehr wie Sand am Meer - und sie haben keine Lust auf unnötige Bürokratie, suchen einen Sinn in ihrer Arbeit und möchten dabei nicht ausbrennen.

Bekannte Agilisten haben sich vor einiger Zeit daran gemacht, die Agilität mit ihren eigenen Methoden weiterzuentwickeln: Ausprobieren und lernen. Alte Zöpfe abschneiden, Neues versuchen. Und an guten Ideen festhalten. Herausgekommen sind Bewegungen wie "Heart of Agile" und "Modern Agile".

Wir machen eine Bestandsaufnahme, wo Agile heute steht. Vor allem schauen wir uns die vier Prinzipien von "Modern Agile" an, warum gerade sie den Weg in die agile Zukunft ebnen. Dieser Vortrag liefert Anregungen und Impulse zur Bewertung des eigenen agilen Vorgehens - und zur Orientierung, wenn jemand gerade vor der Einführung von Agilität im eigenen Unternehmen steht.


ArchUnit: Testen von Architektur und Design

In den meisten Projekten gibt es irgendwo eine Dokumentation der Architektur und der Code-Conventions. Die Frage ist nur: Wo? Und sind die Beschreibungen aktuell? Hält sich der Code wirklich daran? In der Praxis ist solche Dokumentation leider allzu häufig "write-only" und hat mit der Realität nur noch entfernt zu tun.

Viel schöner wäre es doch, wenn die Vorgaben automatisiert geprüft werden könnten. Beispielsweise in Form von Unit-Tests, die von den Entwicklern zusammen mit der Anwendung gepflegt und angepasst werden, als Teil einer "Living Documentation".

Mit der Java-Bibliothek "ArchUnit" können die typischen Architekturvorgaben mit einer Fluent-API als Regeln definiert und z.B. in JUnit getestet werden. Dazu gehören Schichten und fachliche Schnitte, deren erlaubte und verbotene Abhängigkeiten sowie Zyklenfreiheit. Außerdem können Code-Conventions wie Namen von Elementen, die Zuordnung von Klassen zu Packages und die Verwendung von Annotationen und Exceptions geprüft werden.

Bestehende Regeln können so nicht nur mit Unit-Tests festgezurrt werden, es können auch Ausnahmen definiert werden. Vorhandener Code kann so nach und nach an die Vorgaben angepasst werden, z.B. als Vorbereitung einer Modularisierung - und das auch mit älteren Java-Versionen.

Neben der allgemeinen Vorstellung von ArchUnit bietet dieser Vortrag Tipps aus der Praxis - inkl. Live-Coding.


Mob Programming: Learn Together. Deliver Together!

Mob Programming is a way of truly collaborating for whole teams. But - why should we care? We are a team already, aren't we? Well ... Our aim with software development is to deliver the most important feature quickly and in good quality to our customers. Reality looks different, though: Individual workload is maximized, the developers work on too many tasks at the same time. Half-baked features annoy our customers. Developers are fixing bugs around the clock, there's just no time for feature development.

Some years ago, the idea arose of having the entire team carry out software development - together, task by task. "Mob Programming" was born. Blockages during development disappear because all the necessary specialists are in the same room. And if that room is a virtual one, this practice becomes Remote Mob Programming - quite important these days for distributed teams or when working from home.

In this talk I'll show the basics of (remote) mob programming. We'll discuss when working as a "mob" pays off. And I will offer insights and good practices from almost four years of programming "mob style" (and coaching it to various teams in all kinds of companies).


ArchUnit - Unit Testing Architecture and Design

Most projects probably have some kind of documentation of the architecture and code conventions. It's just a question of: Where? And are these documentations up to date? Does the code really adhere to these standards? In the field, documentation is all to often "write-only" and bears only faint resemblance to reality.

Wouldn't it be nice if your architectural and coding rules were checked automatically, as part of your continuous integration build? And if architecture wasn't just an occupation of some distant architect, but rather a team sport for all developers, like in an agile, cross-functional team?

With "ArchUnit" it's possible to code your architectural decisions as plain Java (or Kotlin) rules, using an easy to read fluent API. These rules can check for layered architectures, vertical slices, hexagonal (onion style) architectures, acyclic package dependencies, and for coding conventions like namings, containment of classes in packages and the use of annotations and exceptions. The rules can be checked by any unit testing framework, as for instance JUnit.

You'll see the basics of ArchUnit along with practical tips and tricks, including how to write custom rules. There will be some slides, but mostly live coding.


Past and future events

Developer Week '20

28 Jun 2020 - 2 Jul 2020
Nürnberg, Bavaria, Germany