Social Refactoring – das beste Investment

Im letzten Artikel  habe ich darüber philosophiert, warum das Team verantwortlich ist. Heute geht es um ein extrem wichtiges Thema, und zwar um das Thema “Social Refactoring”.

Viele von uns haben bereits die Erfahrung gemacht, was es bedeutet, in einem agilen Team zu arbeiten, völlig egal ob es nun um Scrum, Kanban oder um etwas völlig anderes geht.

Da ist seit längerem als Scrummaster in einem agilen Team beschäftigt bin (und zuvor auch bereits in sehr vielen unterschiedlichen Teams Scrummaster und auch Entwickler war) kann ich hier ein wenig aus der Erfahrung berichten.

Ich persönlich freue mich immer sehr, wenn Teams engagiert sind, sauberen Code zu produzieren, die gesamte Code-Basis in Clean-Code-Manier sauber zu halten und konstante Refactorings anstreben. Gibts nicht immer, habe ich aber tatsächlich schon erlebt.

Was ich aber auch sehr oft erlebt habe ist, dass die Code-Basis zwar sauber gehalten wird, die sozialen Strukturen im Team aber sträflich vernachlässigt werden. Wie macht sich das bemerkbar?

Kein Collective-Code-Ownershop

Der Code im Team gehört nicht allen, sondern es gibt sie, die Spezialisten. Hier haben wir den EJB-Experten, der sich nur um die Service-Schicht kümmert. Wir haben den JPA-Experten, der alles unterhalb der Repository-Schicht beherrscht. Es gibt den UI-Experten, der funky Oberflächen bastelt. Und insgesamt gilt, jeder verteidigt sein Revier. Da wird geknurrt und gefaucht, was das Zeug hält, sobald ein “Fremder” versucht, im Nachbarrevier zu wildern.

Fingerpointing und Blaming

Ich glaube, dass wir am besten lernen (zumindest ist es bei mir so), wenn wir Fehler machen können/dürfen/sollen, ohne dafür zur Rechenschaft gezogen zu werden. Gerade bei uns in der Entwicklung ist es extrem wichtig, zu experimentieren. Verschiedene Lösungsansätze funktionieren Problemabhängig besonders gut/schlecht, was sich aber meistens nicht sofort beurteilen lässt.

Oft erlebe ich aber, dass jeder Fehler gnadenlos ausgenutzt wird und beinahe unmittelbar der “Blame and Point”-Pattern angewandt wird. Am schlimmsten ist es, wenn dies nicht einmal direkt geschieht, sondern in der Kaffeeküche oder im Code.

Ein Commit-Kommentar den ich kürzlich gelesen habe, lautete in etwa so:

“Clean up this mess. This Code should not be refactored but deleted.”

Dont talk to Strangers

Manchmal finde ich es bedenklich, wie wenig tatsächlich in Teams während der täglichen Arbeit gesprochen wird. Oft erlebe ich es, dass sich jeder um “seinen Kram” kümmert, alles andere ist erst mal egal.

Das Daily-Scrum, dass meiner Ansicht eine Grundlage für nachfolgende Kommunikation sein soll wird oft nur betrachtet als die “nervigen 15 min, damit der Scrummaster Ruhe gibt”.

Jeder schnappt sich seinen Task, “Wiedersehen, wir sehen uns morgen um 10.”.

Nur die Starken kommen in Garten

Die meisten Teams sind durchaus unterschiedlich besetzt (zumindest anfangs). Es gibt die Entwickler mit viel Erfahrung, aber wenig Motivation. (Lieblingssatz: “Haben wir schonmal probiert, funktioniert nicht”).

Es gibt die mit viel Erfahrung und hoher Motivation (die “Keyplayer”, “King of the Hill”, “der Architekt”).

Es gibt Entwickler mit wenig Erfahrung und hoher Motivation (oft “Formbar” oder “Formfleisch” genannt).

Und die “Schlusslichter”, die Entwickler mit wenig Erfahrung und noch weniger Motivation (oft als “Bremsscheibe” tituliert).

Das ist zunächst prinzipiell überhaupt nichts schlimmes und völlig normal. Wenn sich dieses Gefüge aber im Lauf der Zeit nicht ändert und nach 5-6 Sprints immer noch die gleiche Konstellation vorherrscht, dann läuft etwas grandios schief.

Wie wirkt man gegen?

Ich hoffe es wurde klar, dass die Formulierungen von oben sehr überzogen und überspitzt sind. Aber in jeder Formulierung steckt zumindest ein Körnchen Wahrheit. Die Motivation, an bestehenden Misständen etwas zu ändern muss aus dem Team kommen. Wir als Scrummaster können / und sollten hier nur lenkend eingreifen (ich weiß, leichter gesagt, als getan).

Ich bezeichne dieses Vorgehen gerne als “Social-Refactoring” und halte es für genauso wichtig wie Refactoring im Code (und jeder der mich kennt, weiß dass ich Refactoring liebe:)).

Was ist nun die Geheimwaffe des Scrummasters?

Gewalt? Drohung? Blaming? Weinen?

Natürlich nicht, sondern die Retrospektive.

Ich als Scrummaster erlebe es sehr oft, dass die Retrospektive als relativ unnütz, unwichtig und zu langweilig erachtet wird. “Wieso, es läuft doch alles gut” bekomme ich des öfteren zu hören. Als Scrummaster sollte man hier hart bleiben, denn es gibt immer Punkte, über die man sprechen kann. Aus einigen Jahren agiler Erfahrung kann ich sagen, dass Retrospektiven in etwa so etwas wie “Pair-Programming beim Social-Refactoring” sind.

Es gibt zwei Bücher, die ich zum Thema Retrospektive empfehlen würde:

     

Und mein wichtigster Tipp aus der Praxis, denken Sie sich was aus! 

Der grösste Fehler den Sie machen können ist, immer das Gleiche Programm in der Retrospektive abzuspulen. Ich habe es schon erlebt, dass Teammitglieder, die 2 Min vorher da waren schon angefangen haben, ihre üblichen “Zettel” zu schreiben – was lief gut, was schlecht etc. Und das bevor die Retrospektive überhaupt angefangen hat. Da wird es Zeit, gegen zu steuern.

Die Retrospektive muss für die Teammitglieder interessant sein, damit sie wirklich effektiv wird.

Ein Erlebnis, eine Aha!

Beispiel:

Die Mittags-Retro

Wir machen regelmässig eine Mittags-Retro, das Team geht zusammen zum Mittagessen oder holt sich was und setzt sich irgendwo draussen hin und dann wird völlig zwanglos diskutiert. Der Vorteil hiervon ist, dass allein durch den Umgebungswechsel völlig neue Impulse entstehen können und interessante Punkte auf die Agenda gebracht werden.

Stammtisch-Retro

Wieso muss die Retrospektive immer förmlich ablaufen. Manchmal ist es durchaus in Ordnung, die Retrospektive auf kurz vor dem Feierabend zu legen und sich dann ein Bier dazu zu genehmigen. Schafft eine entspannte Atmosphäre und funktioniert erstaunlich gut. Natürlich sollten sich die Teilnehmer dabei nicht betrinken!:).

Hierzu gibt es viele Tipps in den obigen beiden Büchern und ich rate dringend, einfach mal ein wenig experimentierfreudig zu sein und das Eine oder Andere auszuprobieren. Die meisten Teilnehmer danken es einem.

Zu guter Letzt, was ich dringend empfehle ist der sogenannte Team-Radar.

Der Scrummaster liest zu Beginn jeder Retrospektive 5 Begriffe vor, und bittet alle Teammitglieder für diese 5 Begriffe anonym eine Wertung abzugeben auf einer Skala von 1-10. Was daraus entstehen kann, sieht man in diesem Foto.

Team Radar

Agiler Team Radar

Die 5 Begriffe sind immer diesselben. In diesem Fall haben wir die Begriffe

  • Qualität
  • Teamwork
  • Kommunikation
  • Pair-Programming
  • Zufriedenheit

gewählt. Das sind Eigenschaften, Praktiken, Vorgehen die dem Team wichtig erscheinen. Mit diesem Hilfsmittel lässt sich selbst aus Retrospektiven mit wenig Output (gibt es immer mal, beispielsweise kurz vor der Urlaubszeit) noch wichtige Information generieren.

Jeder Sprint bekommt eine eigene Farbe, und auf jeder Achse wird der Mittelwert aller abgegebenen Wertungen eingetragen.

Am Beispiel Qualität lässt sich folgende Entwicklung ablesen:

Entwicklung auf dem Radar

Entwicklung auf dem Radar

Das Team hatte das Gefühl, dass die Qualität über mehrere Sprints immer weiter abgenommen hat. Dies ist natürlich rein subjektiv und hat nicht unbedingt etwas mit der tatsächlichen Code-Qualität zu tun. Hier geht es allein darum, wie das Team empfindet.

Wir haben es über mehrere Sprints nicht hinbekommen, das Gefühl des Teams in dieser Hinsicht zu verbessern, bis wir schließlich irgendwann auf den Trichter gekommen sind, was dem Team so Bauchweh verursacht. Diese Ursache haben wir beseitigt und schließlich im “blauen Sprint” einen ersten Erfolg gefeiert.

Der Team-Radar ist ein wirklich exzellentes Mittel, um die Grundstimmung im Team einzufangen.

Insgesamtes Fazit eines Scrummasters – Social-Refactoring ist wichtig. Selbst das beste Team muss an sich arbeiten. Es funktioniert nicht einfach so, aber jede Minute die ein Team hierfür investiert zahlt sich meistens doppelt und dreifach aus. In diesem Sinne.

War dieser Blogeintrag für Sie interessant? Braucht Ihr Team Unterstützung? Kontaktieren Sie mich, ich bin hier um zu helfen.

Trainings & Know-How aus der Praxis zu

  • Apache Wicket 1.4.x, 1.5.x, 1.6.x
  • GIT – Best Practices, Einsatz, Methoden
  • Spring
  • Java
  • Scrum & Kanban
  • Agiles Arbeiten
Consulting & Softwareentwicklung

  • Requirements Engineering
  • Qualitätssicherung
  • Software-Entwicklung
  • Architektur
  • Scrum & Kanban

Effective Trainings & Consulting - Martin Dilger



Hat Ihnen dieser Blog-Eintrag gefallen? Ich stelle in diesem Blog Informationen über Tools, Frameworks und Werkzeuge zur Verfügung, die mich produktiver machen. Vielleicht kann ich auch Ihnen helfen, produktiver zu werden.


Ich unterstütze Sie als freier Mitarbeiter bei der Entwicklung von Software-Projekten, Agiler Arbeit sowie Schulungen / Fortbildungen.


Jeden Tag ein bisschen produktiver - ab heute