Ein Agile Meetup, mal nicht in einem IT-Unternehmen mit eifrigen Recruitern im Hintergrund. Gibt’s nicht? Gibt’s doch!

Der Einheimische erinnert sich sicher noch an Möbel aus dem Vorzeige Unternehmen, Deutsche Werkstätten Hellerau made in GDR. Heute fertigt das Traditionsunternehmen komplette Inneneinrichtungen für Luxusyachten und Häuser an. Dabei verfolgt man eine sehr offene Philosophie, ein großes Office, eine große flexible Werkhalle. Die Show der letzteren war natürlich ein haptisches Highlight, spannend war aber auch die Feststellung der Unternehmer das sie mit den aktuellen Prozessen an die Grenzen des Machbaren stoßen.

Am Anfang steht nicht mehr als eine fixe Idee. Oft nur eine Skizze aus der am Ende eine 180 Meter Yacht entstehen soll, ganz nach den Wünschen des Kunden. Zum festen Preis, zum festen Termin.

Im aktiven Part des Meetups ging es dann auch darum Ideen für den Start in die Agilität zu finden. Als Brainstorming Game kam 1-2-4-All zum Einsatz, womit gleich auch Liberating Structures am praktischen Beispiel demonstriert wurde. Spannend war am Ende der Outcome der doch bei vielen sehr in Ähnliche Richtungen ging:

• Vorleben und Einführen von agilen Methoden in kleinen Teams
• Schnelles Liefern von Prototypen
• Experimentieren mit Methoden wie Kanban

Die zweite Session konzentrierte sich auf ein anderes Problem. Anett stellt die Frage in die Runde wie ein perfekter Moderationskoffer aussehen sollte. Für mich in Teilen war die Frage nur zum Teil interessant, denn meiner Meinung nach gibt es sowas wie den perfekten, standardisierten Koffer einfach nicht. Mir reichen Grundmaterialien, Schreibzeug, Stickies aus. Alles weitere liegt viel zu stark an den Nutzern.

Neulich hörte ich eine These dazu, warum es in Israel so eine lebendige Startup Kultur gibt. In Israel so sagte der Interviewte, sei das Scheitern kulturell anerkannt und nicht verpönt wie hier in Deutschland.

Klar, sind wir hier doch schon von der Schule an auf maximale Leistung und beste Noten getrimmt. Willste den NC deines Traumstudiums schaffen müsste eben büffeln. Egal ob das gelernte einen probaten Mehrwert bietet oder nicht.

Klassischer Projektablauf nach Pflichtenheft und Wasserfall folgt ebenfalls diesem Prinzip. Alles muss vollständig geliefert werden. Egal ob die Hälfte eigentlich keinen echten Mehrwert liefert.

Agiles Vorgehen wiederum sieht das Scheitern als integralen Teil des Prozesses. Aus Fehlern kann man lernen, von daher sind sie auch nichts an sich schlechtes. Ein guter Scrummaster gar muss lernen sein Team Fehler machen zu lassen, selbst wenn er es eigentlich besser wüsste.

Und ganz tief am Boden unseres physischen Seins hat schon alte Darwin erkannt daß die ganze Evolution allein auf Fehlern basiert. Für das einzelne Gen ist es zwar total doof wenn es nicht überlebt, aber das gesamte System hat sich in der nächsten Generation verbessert, weil es eben ein bestimmtes Gen als Fehler erkannt und eliminiert hat.

Somit hat jeder Fehler seine Daseinsberechtigung, jeder Fehler hat durch zukünftige Vermeidung einen Mehrwert. Fehler in diesem Sinne also Grundlage von Erfolg im allgemeinen sind.

Als Nutzer von GIT als Versionsverwaltung dürfte einem bewusst sein das die Historie nicht
in Stein gemeißelt ist. Commits können sowohl lokal als auch remote auf dem Server verändert
werden. Eine recht verbreitete
Variante dieser Veränderung ist der “Squash”.

Tatsächlich kann man vortrefflich darüber streiten ob es sinnvoll oder vielleicht sogar
gefährlich ist die Historie in einem System zu verändern dessen elementare Aufgabe es ist
eben diese zu bewahren. Für mich ist der Squash in erster Linie ein Mittel um einen Feature-Branch
aufzuräumen, bevor dieser zurück in den master-Branch fließt.

Dabei ist es für mich ein absolutes No-Go blind sämtliche Commits zusammenzuführen nur damit die
Zahl der Commits gering gehalten wird. Wohl aber finde ich es sinnvoll über die Commits zu gehen,
eventuell logisch zusammenhängende Commits zusammenzuführen oder neu zu sortieren. Kleine Fehlercommits
ala “tippfehler korrigiert” interessieren im Nachgang auch niemanden.

Zwiespältig sehe ich das entfernen von Commits die einen Fehler produziert haben. Handelt es sich
um einen Flüchtigkeits- oder Tippfehler dann kann der mMn gerne weg. Bei Denkfehlern kann ein zweiter
Commit mit einer Korrektur und einem Hinweis auf diese vielleicht für einen Reviewer oder interessierten
Codeleser weiter helfen dieses Problem selbst zu vermeiden. Muss man also von Fall zu Fall entscheiden.

Was schon aufgrund technischer Gefahren nicht passieren sollte sind Änderungen der Historie auf dem
Master-Branch, oder auch auf Intergrations-Branches. Diese werden typischerweise von mehreren Entwicklern
verwendet, gar kontinuierlich geliefert und was geliefert wurde sollte sich nach der Lieferung auch
nicht mehr verändern.

Pair-Programming ist allgemein eine ziemlich doofe Zielsetzung. Klar mal für ein Problem, oder ein Experiment mit dem Kollegen am Rechner kuscheln ist ganz nett. Längere Sessions ermüden mich persönlich allerdings doch schnell und es schleicht sich dann auch bald ein Gefühl der Ineffizienz ein. Dabei lernt man gemeinsam neue Technologie kennen, teilt direkt das Wissen und steigert die Qualität des Produktes. Ganz nebenbei lernt man auch den Stil und die Denk- und Arbeitsweise der Kollegen kennen. Gerade letztere können aber stark von der eigenen abweichen und damit sind Konflikte eigentlich vorprogrammiert.

Ich persönlich bin also eher nicht der Pair-Programming Typ. Die oben genannten Vorteile finde ich persönlich in einem eigentlich stärker qualitätsorientieren Verfahren wieder, dem: Code-Review.

Leider kannte ich Code-Reviews bis vor einiger Zeit Code-Reviews primär als zufälliges Ereignis, bei dem dann typischerweise ein Verriss des untersuchten Codes stattfand. Grund für diese Reviews war meist, ein beim Testen aufgetretener Fehler, der einen anderen Entwickler auf den Plan rief. Ergo war das Review unbeliebt und unproduktiv.

Die zweite Variante die ich kannte war das öffentliche Code Review mit Beamer und großem Auditorium. Dabei wurden dann meist komplexe Codes an die Wand geworfen und spätestens nach 10 Minuten wich die Stimme des Präsentierenden dem angenehmen Rauschen des Beamers, das irgendwann wiederum durch ein: “noch Fragen” jäh unterbrochen wurde.

Die Wirklich geile Version des Code-Reviews aber ist die, welche stetig durchgeführt wird. Stetig weil sie Teil einer Definition of Done ist und weil jede Codeänderung, egal ob Bugfix oder Feature, von mindestens einem zweiten Entwickler begutachtet wird.

Wie schon erwähnt funktioniert das nur in einer Umgebung die konstruktiv und objektiv zu arbeiten bereit ist. Nicht jeder Entwickler hat die gleichen Ansprüche und Voraussetzungen, daher muss beim Review klar sein, dass der Code des anderen durchaus in Ordnung sein kann auch wenn man ihn selbst so niemals geschrieben hätte.

Allgemein habe ich Code-Reviews in meinen letzten Projekten als sehr hilfreich erfahren und lieben gelernt. Zum einen lernt man so den Stil- und die Lösungsstrategien der Kollegen kennen, zum anderen lernt man neuen heißen Scheiß kennen. Auf jeden Fall hat man am Ende immer das Gefühl als Team ein besseres Ergebnis geliefert zu haben.

Klar fasst man sich manchmal dabei an den Kopf, wenn man merkt was man da für einen Schmarn geschrieben hat, oder wie umständlich der andere gedacht hat, diese Minuten des WTF-Gemurmels werden aber meines Erachtens durch Lerneffekt und Qualitätsgewinn mehr als aufgewogen.

Ein Allheilmittel ist das Code-Review natürlich nicht. Vor allem zu komplexe und umfangreiche Änderungen sind schlecht für Reviews geeignet, sind aber dann auch Anzeichen für andere Probleme im Entwicklungsprozess.

Weil ich jedesmal beim Rechner-Setup danach suchen muss wie man die Buttons in der Titelzeile nach Rechts bekommt, wo sie mein motorisches Gedächtniss erwartet:

gsettings set org.gnome.desktop.wm.preferences button-layout ':minimize,maximize,close'