Fast alle Entwicklerteams haben ein gemeinsames Problem: der Alltag wird durch umzusetzende Funktionalitäten geprägt. Es bleibt kaum Zeit für Weiterentwicklung. Motivierte Entwickler versuchen dies in ihrer Freizeit, wenngleich dies oftmals aufgrund einer Familie oder anderweitigen Verpflichtungen nicht einfach umzusetzen ist. Weniger motivierte Teammitglieder erfüllen ihr tägliches Arbeitspensum, entwickeln sich aber kaum weiter. Ein mögliches Ergebnis ist, dass sich die Code-Qualität beständig verschlechtert, Teile der Software im schlimmsten Falle neu implementiert werden müssen, oder aber, sich zahlreiche Fehler einstellen. Doch wie kann man dem entgegen wirken?

Mögliche Problemstellen identifizieren

Der zentrale Punkt ist die Feststellung der aktuellen Problemstellen. Diese können unterschiedlichster Natur sein. Aus meiner Erfahrung bewegen sie sich hauptsächlich in den folgenden Bereichen:

  • Mangelnde Kommunikation
    Informationen werden gar nicht, nicht zeitgerecht oder nur ungenügend weitergegeben. Dies beginnt beim Team Lead, der dem Team relevante Informationen (beispielsweise aus angrenzenden Teams, Business-Entscheidungen, etc.) vorenthält. Vielfach betrifft dies aber auch Umsetzungen innerhalb des Teams. So werden neue Konzepte, eingesetzte Patterns usw. nicht ausreichend kommuniziert. Ganz schwierig wird die Situation, wenn weitere Teams (mit Abhängigkeiten) involviert sind.
  • Fehlende Motivation
    Ein demotiviertes Teammitglied kann (und wird es in den meisten Fällen auch) sich sehr negativ auf das gesamte Team auswirken. Eine fehlende Motivation kann als Ursache eine Unter- oder Überforderung haben, oder es gibt Probleme grundsätzlicher Natur am Arbeitsplatz (Ausstattung, Klima, …).

Problemstellen minimieren

Nach der Lektüre einiger Quellen, zahlreichen Gesprächen und Diskussionen hat sich heraus gestellt, dass die nachfolgenden Varianten allesamt nicht zum Ziel führen (können). Es gilt sie definitiv zu meiden, da jegliche Weiterentwicklung dadurch verhindert wird:

  • Druck aufbauen
    Druck kann auf unterschiedlichste Arten aufgebaut werden. Meist ist davon ohnehin schon genug vorhanden, vor allem im Projektgeschäft.
  • Probleme diskutieren
    Es ist wenig sinnvoll, lange Zeit über die aktuellen Probleme zu diskutieren, da ohnehin kaum Lösungen aus diesen Gesprächen/Diskussionen zu erwarten ist. Oftmals verlaufen zwei bis drei Tage besser, danach stellt sich das alte Verhalten wieder ein.
  • Mitarbeiter auf Fehler hinweisen
    Fehler müssen behoben werden. In der Regel ist es aber irrelevant, wer den Fehler begangen hat. Ihn gezielt darauf hinzuweisen wirkt natürlich demotivierend.

Wie dies aber angehen ohne demotivierend zu wirken und vielleicht sogar die Motivation zu heben (und wenn schon nicht das, dann zumindest doch die Qualität zu verbessern)? Einige mögen nun meinen:

Hey, schreibt doch Unit Tests!

Das ist schön und gut. Aber alle Anstrengung darauf legen muss, seine Punkte durch zu bekommen, schreibt keine Tests (hinzu kommt auch noch die fehlende Gewohnheit). Da hilft selbst das Wissen um die “angeblichen” Vorteile nichts. Der Start kostet Zeit, Zeit die niemand investieren möchte/kann. Also muss man andere Lösungen finden, um in einer lockeren Atmosphäre an diese Themen heran zu führen.

Code Reviews

Vertrauen ist gut, Kontrolle ist besser. Code Reviews sollten ein wichtiger und vor allem täglicher Bestandteil der Softwareentwicklung sein. Natürlich kann nun der Lead selbständig den Code begutachten und Problemstellen mit dem betroffenen Entwickler abstimmen, aber dies kann recht schnell nach hinten los gehen (siehe Demotivation etc.). Besser sind Code Reviews im gesamten Team, da hier das Feedback von mehreren (teilweise unterschiedlichen) Leuten kommt und die Akzeptanz beim betroffenen Entwickler (aus meiner Erfahrung) wesentlich höher ist.

Durch das Wissen um regelmäßig stattfindende Code Reviews wird zusätzlich auf Fehlerfreiheit und Sauberkeit des Codes geachtet. Niemand möchte bloßgestellt werden. Nun mag man meinen:

Aber das ist doch auch eine Form von Druckaufbau

Ja, ist es. Aber dieser Druck kommt nicht von einer Person (Team Lead), sondern aus dem ganzen Team und wird daher anders aufgenommen und verwertet.

Wichtig: Der Team Lead ist dafür zuständig, dass hier eine Regelmäßigkeit entwickelt wird. Vereinbarte Reviews müssen unbedingt eingehalten werden, da “Terminabsagen” – wenn auch nur einmal geplant – nach Wiederholung schreien. Das Ziel muss sein, dass Code Reviews abgehalten werden, selbst wenn der Team Lead nicht verfügbar ist.

Welche “Regeln” haben sich für mich als zielführend für einen erfolgreichen Start von Code Reviews im Team erwiesen:

  • Größere Umsetzungen, die einen mehrstündigen oder mehrtägigen Aufwand nach sich ziehen sollten unbedingt vor dem Check-In begutachtet werden. In vielen Fällen ist es jedoch sinnvoll auch zwischendurch ein Review zu machen um feststellen zu können, ob die Entwicklung in die vorgesehene Richtung geht. So können frühzeitig Korrekturen vorgenommen werden.
  • Kleinere Check-Ins werden täglich zu einem festgesetzten Termin durchgesehen. Dies inkludiert auch Änderungen etwaigen Ressourcen (beispielsweise von Übersetzungen), oder aber auch Projekt- und Solution-Dateien.
  • Zu Beginn sollten Reviews immer im gesamten Team durchgeführt werden. Hat sich eine Regelmäßigkeit eingestellt, kann dies auch nur zwischen zwei Personen geschehen (besser jedoch 2 Personen + Team Lead als Moderator)

Gerade in der Einführungsphase halte ich persönlich wenig davon (außer es ist auf Grund der Gegebenheiten nicht anders machbar) Reviews räumlich getrennt bzw. über diverse Medien abzuhalten. Am besten eignet sich ein Beamer oder ein Rechner um den sich das Team versammelt. Dies fördert das soziale Verhalten, Reaktionen von anderen werden besser erkannt und können eingeordnet werden und fördert zusätzlich auch das Zusammengehörigkeitsgefühl. Auch hier gilt: Haben sich Reviews eingespielt, kann man auf andere “Werkzeuge” umsteigen.

Coding Dojos

Ich könnte nun Coding Dojos erklären, ihren tieferen Sinn erläutern, wie auch immer. Gerne möchte ich an dieser Stelle aber an jemanden verweisen, der das weit besser kann als ich, Ralf Westphal. Sein Artikel Gezieltes Coding Dojo hält vieles an Information bereit, viele Verweise (beispielsweise auf Artikel von Ilker Cetinkaya, dessen Blog generell äußerst lesenswert ist), angereichert um zahlreiche Ideen und Gedanken.

Was ich jedoch betonen möchte: Ein team-internes Coding Dojo in dessen Rahmen gemeinsam eine Lösung erarbeitet werden muss, bietet einige Vorteile, die es unbedingt zu bedenken gibt:

  • Es macht Spaß
  • Die tägliche Arbeit und deren Aufgabenstellungen können für eine kurze Zeit verdrängt werden
  • Im Vordergrund steht der Gedanken-/Wissensaustausch
  • Jeder kann vom anderen lernen
  • Es fördert die Teamzugehörigkeit
  • Hilft, eine solide soziale Basis zu schaffen

Natürlich können hier Gegenargumente vorgebracht werden. Beispielsweise:

Aber das kostet doch schon wieder Zeit!

Ja. Und? Wir reden hier nicht von Tagen, die dafür aufgewendet werden einen blöden Fehler zu suchen. Wir reden von beispielsweise einer Stunde pro Woche, in der sich das ganze Team auf allen Ebenen weiterentwickelt. Dadurch können unter anderem

  • einfach neue Methodiken und Technologien vermittelt
  • Unit Tests zur Gewohnheit
  • Kommunikation gefördert

werden. Quasi für lau. Auch hier ist eine Regelmäßigkeit unabdingbar. Findet sich diese ein, funktionieren plötzlich auch andere Dinge automatisch. Werden für die Umsetzung von Katas im Rahmen eines Coding Dojos Unit Tests vorausgesetzt, dann erkennt man im Team recht schnell deren Vorteile (vor allem wenn sich mal jemand nicht daran gehalten hat) und der Weg in die tägliche Arbeit ist nicht mehr mit den üblichen Vorurteilen und Hindernissen behaftet.

Das Beste erfolgt zum Schluss: Hier gibt es keinen Fingerzeig auf eine einzelne Person, keine Demotivation.

Fazit

Jeder Team Lead, jeder Entwickler hat seine Stärken und Schwächen. Niemand kann die Schwächen eines anderen abtrainieren, aber man kann (und das ist auch die Aufgabe eines Team Lead) die Stärken seiner Team-Mitglieder stärken und durch Maßnahmen versuchen, die Schwächen zu mildern. Die von mir genannten Beispiele sind sicherlich keine Allheilmittel. Es sind Wege, die ich aktuell beschreite um Verbesserungen sanft zu erlangen, nicht zu erzwingen. Ob ich damit auf dem richtigen Weg bin wird sich weisen. Welche Erfahrungen, Beobachtungen hast du gemacht? Welche Wege schreitest du?

Über den Autor

Norbert Eder

Ich bin ein leidenschaftlicher Softwareentwickler und Fotograf. Mein Wissen und meine Gedanken teile ich nicht nur hier im Blog, sondern auch in Fachartikeln und Büchern.