Kolumne

DevOps Stories: Ich komme hier zu nichts! Was Unterbrechungen für Entwickler bedeuten

Konstantin Diener

©SuS_Media

Alle Mitglieder des MusicStore-Teams sitzen an ihren Computern und haben Kopfhörer auf den Ohren. Außer dem Klappern der Tastaturen sind keine Geräusche im Raum zu hören. Auf einmal kommt Erik, der Product Owner, zur Tür herein und spricht die Kollegen an.
 

  • Erik: „Hey, ihr Lieben, ich habe gerade Deborah aus dem Marketing zufällig…

Erik stellt fest, dass keiner der Kollegen auf ihn reagiert. Er stellt sich in Positur und gestikuliert wild, bis alle ihre Kopfhörer abgezogen haben.

  • Christian: „Was willst du, Erik?
  • Erik: „Ich habe gerade Deborah aus dem Marketing zufällig in der Küche getroffen und wir hatten ein super Gespräch…
  • Christian: „Und deswegen störst du uns? Meinst du, wir haben die Kopfhörer einfach so auf?
  • Erik: „Ich dachte, ihr hört Musik! Naja egal, Deborah hat mich auf eine super Idee gebracht und ich würde gerne mit euch noch diese Woche einen Designworkshop machen…
  • Christian: „Wir wollen nicht einfach nur Musik hören. Du hast mich jetzt hier aus dem Thema voll rausgebracht! Kannst du uns nicht einfach eine Slack-Nachricht schreiben?
  • Erik: „Dann hättet ihr möglicherweise erst spät geantwortet. Deborah ist nur noch eine halbe Stunde im Büro und ich möchte den Workshoptermin gerne mit ihr abstimmen.
  • Lukas: „Was schwebt dir denn vor?
  • Erik: „Am liebsten wäre mir am Mittwoch nach dem Review!
  • Christian: „Da haben wir Retro.
  • Erik: „Stimmt. Dann hätte ich am Mittwoch irgendwann nach der Retro gerne eine halbe Stunde Vorbereitung mit euch und dann können wir den Workshop Freitag ab 10:30 Uhr machen.
  • Lukas: „Geht es freitags auch eine halbe Stunde früher? Wir haben um 9:45 Uhr Standup.
  • Erik: „Nein, da können Deborah und ich nicht…
  • Christian: „Erik, wann meinst du, kommen wir hier noch zum Coden? Du zerstückelst uns mit deinen Terminideen jeden Tag in der Woche!
  • Erik: „Aber das ist doch ein wichtiges Thema! Außerdem könnt ihr doch zwischen den Terminen coden!
  • Christian: „Wann? Am Freitag in den dreißig Minuten zwischen Standup und deinem Workshop? Oder am Mittwoch nach der Retro ab 16:00 Uhr? So lange, bis du uns mit deiner halben Stunde Vorbereitung unterbrichst?
  • Erik: „Ist das unrealistisch?
  • Christian: „Pfff, man merkt, dass du nie Software entwickelt hast!

Jede kreative Tätigkeit erfordert „Flow“

Das Buch „Peopleware“ (im Deutschen „Wien wartet auf dich!“) von Tom De-Marco und Timothy Lister [1] hat den Begriff „Flow“ in der IT-Branche bekannt gemacht. Für jede kreative Tätigkeit (Softwareentwicklung, Design, Schreiben usw.) ist es unabdingbar, dass wir in den Flow bzw. in Fahrt kommen, wie es in der deutschen Übersetzung heißt. In diesem Zustand sind wir voll auf die jeweilige kreative Aufgabe fokussiert und vergessen die Zeit und die Welt um uns herum. Jede Störung und jeder Kontextwechsel führen zur Unterbrechung dieses Zustands. Untersuchungen zeigen, dass es ungefähr fünfzehn Minuten braucht, bis wir danach wieder in den Zustand zurückkehren können.

Im modernen Büroalltag gibt es eine Vielzahl an Quellen für solche Störungen. Die gängigsten sind beim MusicStore-Team schon ausgeschlossen. Das Team arbeitet nicht in einem Großraumbüro, sondern hat einen eigenen Teamraum. Die Störungen durch andere Teams sind so auf ein Minimum reduziert. Ein Telefon hat außer Manuela, der Supportkollegin, niemand im Raum, und um wirklich ungestört arbeiten zu können, haben sich alle Entwickler Kopfhörer aufgesetzt. Dass Erik erst gestikulieren muss, damit die anderen ihn beachten, spricht auch dafür, dass die Kopfhörer sogar Umgebungsgeräusche ausblenden. Aber selbst dann bleibt noch der Rechner als Quelle für Störungen: Neue E-Mails, Slack-Nachrichten etc. können immer noch zu Kontextwechseln und damit zu einem Verlassen des Flow-Zustands führen. Vermutlich haben die Kollegen auch diese Benachrichtigungen abgeschaltet. Erik wollte bewusst keine Slack-Nachricht schicken, weil ihm die Antwort zu lange gedauert hätte.

DevOpsCon Whitepaper 2018

Free: 40+ pages of DevOps expert knowledge

Learn about Containers,Continuous Delivery, DevOps Culture, Cloud Platforms & Security with articles by experts like Kai Tödter (Siemens), Nicki Watt (OpenCredo), Tobias Gesellchen (Europace AG) and many more.

Jedes Entwicklungsteam braucht (Zeit-)Räume für Stillarbeit

Erik ist vermutlich nicht klar, was er mit seiner Intervention anrichtet – dass die Kollegen nämlich nach diesem Gespräch noch mindestens eine Viertelstunde brauchen werden, um wieder in Fahrt zu kommen. Christian ist der Meinung, sie hätten es sehr deutlich dadurch gezeigt, dass sie Kopfhörer tragen. Diese Regel sollte das Team vermutlich deutlicher hervorheben: „Wenn wir die Kopfhörer aufhaben, wollen wir nicht gestört werden.“

Es muss aber nicht zwingend immer eine Störung von außen sein, die das Team immer wieder aus dem Flow reißt oder es gar nicht in diesen Zustand kommen lässt. Agile Teamarbeit lebt von der Kommunikation untereinander. Sie ist wichtig und stärkt ein gemeinsames Verständnis. Es gibt aber auch ausreichend Gelegenheiten, zu denen die Mitglieder einfach mal konzentriert an etwas arbeiten müssen. Viele Teams führen zu diesem Zweck sogenannte Stillarbeitszeiten ein, die ähnlichen Regeln wie der Aufenthalt in einer Bibliothek unterliegen.

Wenn Erik die Tragweite seiner Störung klar wäre, würde er vermutlich anders handeln. Er würde dem Team eine Nachricht zukommen lassen, die sie bearbeiten können, wenn sie ihre Stillarbeitsphase beendet haben (z.B. für die Mittagspause). Dafür eignen sich asynchrone Kommunikationssysteme wie E-Mail oder Gruppenchats. Nach außen erzeugt es oft ein befremdliches Bild, wenn Menschen nebeneinander in einem Raum sitzen und sich Nachrichten schreiben. Wenn man Kreativarbeiter nicht aus dem Flow reißen will, ist das aber durchaus nützlich.

Störungen zu visualisieren, sorgt in vielen Teams für Überraschungen

Christian und die anderen können in diesem speziellen Fall sehr genau benennen, dass eine Störung stattgefunden hat. Das ist nicht bei jeder Störung der Fall. Außerdem ist den Teams meist nicht klar, wie viele Störungen es gab und was deren Auswirkungen sind. Nicht selten teilen Teams in ihrer Retrospektive das Gefühl, dass sie im zurückliegenden Sprint nichts geschafft haben und zu nichts gekommen sind. Sie können aber keinen exklusiven Grund dafür benennen („Es war doch ständig irgendwas“). In diesem Fall hilft es, die Störungen zu dokumentieren und in der nächsten Retrospektive zu analysieren. Das gängigste Werkzeug hierzu ist die sogenannte „Pain Snake“ (Abb. 1). Hier hängt das Team für jede Störung einen Klebezettel hinten an die Schlange an. Meist sind die Teams dann in der Retrospektive überrascht, wie lang die Schlange geworden ist.

Abb. 1: Mit der „Pain Snake“ können Störungen besser sichtbar gemacht werden

Abb. 1: Mit der „Pain Snake“ können Störungen besser sichtbar gemacht werden

In „Fifty Quick Ideas to Improve your Retrospectives“ [2] wird vorgeschlagen, den Störungen farbige LEGO-Steine zuzuordnen. Für jede Störung wird ein entsprechender LEGO-Stein in ein großes Glas geworfen und das Glas in der Retrospektive ausgeleert.

Ein zerstückelter Tagesablauf und ständige Störungen

Bislang haben wir uns nur mit ungeplanten Störungen beschäftigt, es existieren aber auch geplante Störungen, die für den Flow des Entwicklungsteams ähnlich problematisch sind. Diese geplanten Störungen entstehen, wenn der Tagesablauf des Teams im Extremfall mit lauter kurzen Besprechungen mit Abstand von dreißig bis sechzig Minuten gefüllt ist. Bei den Entwicklern entsteht zu Recht der Eindruck, dass man in einem Dreißig-Minuten-Zeitfenster gar nicht anfangen müsse, da man ja ohnehin nichts Sinnvolles fertigbekommt. Immerhin wird die Hälfte des Zeitfensters nur verwendet, um in den Flow zu kommen.

Erik sieht das Problem nicht. Das könnte mit einem Phänomen zu tun haben, das im oben erwähnten Buch „Peopleware“ folgendermaßen beschrieben ist: „Wenn Sie als Manager arbeiten, dann haben Sie vielleicht nicht viel Verständnis für die Frustration, die entsteht, wenn man aus den Gedanken gerissen wird. Denn Ihre Arbeit ist hauptsächlich interruptgetrieben – das ist Management; aber Ihre Mitarbeiter müssen in Fahrt kommen.“

Erik arbeitet vermutlich sehr interruptgetrieben. Es ist für ihn also völlig normal, dass die Woche aus vielen kleinen Terminen besteht und er einen zerstückelten Tagesablauf hat. Die Entwickler haben aber nie ausreichend Zeit am Stück, um in Flow zu kommen und dann einige Stunden in diesem Zustand zu arbeiten.

Der Unterschied zwischen der Zeitplanung für Entwickler und für Manager wird als „Manager vs. Maker Schedule“ bezeichnet. Der Manager ist interruptgetrieben und teilt seinen Kalender in Zeitfenster von einer Stunde ein. Er ist daran gewöhnt, dass sich das Thema jede Stunde ändert. Mit solch einem Kalender kann ein Entwickler aber nie in den Flow kommen. Sein Kalender besteht aus viel größeren Blöcken, die sich z.B. an den Pausen orientieren (Abb. 2). So teilt sich dieser Kalender bspw. in die Blöcke „Standup bis Mittagessen“ und „Mittagessen bis Feierabend“. Die Entwickler sollten sich einen oder wenige dieser Blöcke pro Woche für Termine reservieren. Die Kollegen wissen dann, dass sie Termine in diese Blöcke legen sollten, um die Arbeit des Teams so wenig wie möglich zu stören. Muss ein Termin in einem der anderen Blöcke stattfinden, sollte er nach Möglichkeit am Anfang liegen – wenn der Entwickler noch nicht in seinen Flow investiert hat.

Abb. 2: Aufbau eines Manager- und eines Maker-Kalenders

Abb. 2: Aufbau eines Manager- und eines Maker-Kalenders

Das Team hat mit seinem Scrum Master besprochen, solche Blöcke einzurichten, feste Stillarbeitszeiten mit klaren Regeln zu definieren und mindestens morgens vor dem Standup sowie vor dem Feierabend Mails und Slack-Nachrichten zu beantworten.

Geschrieben von
Konstantin Diener
Konstantin Diener
Konstantin Diener ist CTO bei cosee. Sein aktueller Interessenschwerpunkt liegt auf selbstorganisierten Teams, agiler Unternehmensführung, Management 3.0 und agiler Produktentwicklung. Daneben entwickelt er noch leidenschaftlich gerne selbst Software. Twitter: @onkelkodi
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: