Fuehrung

Vor längerer Zeit habe ich als Product Owner mit einem Entwickler-Team zusammengearbeitet. Das Team entwickelte mit Java + Vaadin eine Webanwendung. Als sich die Probleme und Bugs häuften und auch teilweise wiederholten, erkundigte ich mich, ob zu den aufgetretenen Bugs auch dazugehörige Unit-Tests beim Beheben erstellt worden seien. Für jeden Bug ein Unit-Test Das Prinzip, für jeden Bug einen Unittest zu schreiben, hat den Zweck, sogenannte Regressions zu verhindern. Damit ist gemeint, dass ein Bug in der Zukunft wieder auftaucht und erneut behoben werden muss. ...

Gestern ergab es sich, dass ein Kollege und ich in eine Refactoring-Session gestolpert sind. Verschiedene Vorschläge ergänzten sich, aber eines hat mir besonders Spaß gemacht… Als erstes schlug mir IntelliJ folgendes vor: Danach ging es direkt mit dem nächsten Hinweis weiter … Meiner Meinung nach ist es extrem wichtig, die richtigen bzw. gute Werkzeuge zu nutzen, um gute Ergebnisse zu erzielen. Dann macht die Arbeit Spaß und das ist jeden € wert, den die Werkzeuge letztendlich kosten.

Ein Post-Mortem wird häufig im Projekt-Management eingesetzt, um zu analysieren, warum ein Projekt nicht erfolgreich abgeschlossen werden konnte. Im Bereich IT Operations habe ich das Konzept als RCA (Root Cause Analysis) kennengelernt. In der Software-Entwicklung habe ich dieses Konzept bisher noch nicht angetroffen. Auf Störungen im Betrieb wird meistens durch das Erstellen und Bearbeiten von Tickets reagiert. Wir haben Post-Mortem bei uns vor mehr als einem Jahr eingeführt und pflegen ein Dokument, in dem wir jeden Vorfall eintragen und die daraus abgeleiteten Maßnahmen protokollieren. ...

Diese Aussage kam im Gespräch mit einem Kollegen. Meine anfängliche Verwunderung hat sich über Nacht zu einem Thema entwickelt, das mich mehr beschäftigt als ich erwartet hätte. Meine erste These ist, dass wir als Verantwortliche implizit davon ausgehen, dass die Entwicklung qualitativ hochwertige Lösungen liefert, gleichzeitig aber widersprüchliche Signale geben, weil die gewünschte Lösung ja möglichst günstig und schnell umgesetzt werden soll. Meine zweite These ist, dass Qualität für uns EntwicklerInnen anstrengend und natürlich auch zeitaufwändig ist. Die Versuchung ist groß, sich dem zu entziehen und schnell irgendwas über den Zaun zu werfen, was irgendwie (hoffentlich) das gewünschte Ergebnis liefert. ...

Heute hatten wir unsere regelmäßige Führungsklausur, an der ich teilnehmen durfte. Im ersten Workshop ging es um das Thema Mitarbeiterzufriedenheit. Unter anderem ging es auch um Mitarbeitergespräche. Ein guter Anlass für mich, mein Lieblingswerkzeug, die Manager Tools One On Ones (MTO3s) zu beschreiben. Kennengelernt habe ich es 2013 im Manager-Tools-Podcast, als ich meine erste Position als Führungskraft übernommen habe und mich vorbereiten wollte. Das Konzept Nur, wer die Menschen im Team wirklich kennt, kann gut führen. Um dies zu erreichen ist ein regelmäßiger Austausch unerlässlich. Den Ablauf und die Frequenz des Austauschs wurden laut Mark Horstmann (in seinem Buch The Effective Manager), in vielen Versuchen ermittelt, welche zu folgenden Empfehlungen führen: ...