Sparringspartnering: Reflexion am Arbeitsplatz

Ha, Sparringspartner! Wozu? Die Komfortzone ist ein schöner Ort. Die Arbeit dort geht flott, relativ flott. Man kennt ja alles. Aber leider lernt man auch sehr wenig. Ist das da Bräunliche da Rost?

Es gibt eine schöne Übung im Agile-Kontext, in der ein Team unter Beachtung von ein paar Regeln möglichst schnell etwas mit Tennisbällen machen muss. Wie im Zeitraffer kann man Phasen der „Ruhe“ beobachten, in der die Teilnehmer im Detail an ihren Abläufen feilen oder sich „mehr anstrengen“. Aber dann gibt es auch immer wieder Zäsuren, an denen jemand ruft „ich hab noch ne ganz andere Idee“. Es bleibt dann selten bei genau dieser Idee, sondern es kommen ganz schnell von vielen hilfreiche Modifikationsvorschläge. In den darauffolgenden Runden gibt es dann oft einen riesigen Sprung im Output, obwohl sich eigentlich niemand mehr anstrengen muss.

Jeder Mensch tendiert zu diesen längeren Komfortzonen-Phasen, auch Entwickler. Das ist gut und wichtig, denn in diesen Phasen wird viel Arbeit geschafft. Gerade unter Stress und Druck ist der Komfort essentiell, denn mit altbewährten Automatismen lässt es es sich am schnellsten arbeiten. Allerdings werden in solchen Phasen eben auch Lernerfahrungen unwahrscheinlicher.

Wer liefert also die Zäsuren, die Zeiten, in denen die Arbeitsprozesse eine kreativen Betrachtung unterzogen werden können? Wer ermutigt dazu, mal einen Ausflug in ganz neue Entwickler-Sphären zu wagen?

In einem tollen, agil arbeitenden Team wird das vermutlich das Team selbst schaffen. Bis es soweit ist, kann ich als Sparringspartner helfen.

Ziel

Ziel ist es, den Mitarbeitern ein Kontingent an „Zäsuren“ und „Lernzeit“ zur Verfügung zu stellen. Bei Bedarf unterstützte ich auch gern das Erarbeiten einer komplett neuen technischen Domäne über längere Zeit.

Variante „Standard“: ~n*2h

Variante „neuen technischen Domänen“: n*4d

Das Team bekommt ein Kontingent von zwei Coaching-Stunden pro Person.
In den Fokus der Aufmerksamkeit könnten Fragen zu den folgenden Bereichen rücken:

  • Verworrenen Arbeitsabläufen
  • Nicht-Nutzung hilfreicher Features, Techniken oder Technologien
  • IDE-Bedienung (Shortcuts)
  • Dysfunktionaler Kommunikation
  • „Computer-Esoterik“ („Da muss man neu starten. Das hab ich mal irgendwo gehört. Und dann hat das auch funktioniert!“)
  • Gliederung von Abläufen oder Hilfe bei Unruhe, Abschweifen, etc.

Beim Erarbeiten ganz neuer technischer Domänen unterstütze ich mit z.B. acht halbtägigen Sessions. Fragen werden hier sein:

  • Was wollen wir uns aneignen?
  • Wo werden wir es zum ersten mal hilfreich einsetzen können?
  • Wie nähern wir uns der Thematik an? Können wir dabei Synergien schaffen? (Buch, Tutorial, Übungsprojekt, kleiner Prototyp, Serie von Unit-Tests?)

Ergebnisartefakte

  • Die langfristige Tendenz, sich Fragen zu eigenen Arbeitsabläufen und zum Verständnis von Code zu stellen, steigt. (nicht messbar)
  • Mehr Spaß bei der Arbeit, weniger Lästiges, mehr Produktivität, mehr Wissen. (bedingt messbar)
  • Ein mittelfristiger Zugewinn an Team-Velocity. (messbar)

Kommentar verfassen