„Früher haben wir jeden Tag zwei bis drei Stunden in Meetings verquatscht, das war verschwendete Zeit“, sagte ein Entwickler kurz nach dem Beginn meines Engagements in seinem Scrum-Team zu mir. Aber dann: „Und jetzt quatschen wir den ganzen Tag im Team-Raum. Mit dem PO, mit UX- und Security-Experten oder weiteren Stakeholdern, um ‚schnell und direkt‘ Nachfragen zu Stories zu klären. Mit den anderen Entwicklern aus unserem Team, um Architekturen und Lösungskonzepte zu diskutieren. Mit den Kollegen aus anderen Teams, um Schnittstellen abzustimmen. Und jetzt mit dir, unserem Scrum-Master, weil ich davon genervt bin, dass ich nicht zum Coden komme. Vielleicht sollten wir das in der nächsten Retrospektive thematisieren; also schon wieder reden, reden, reden, anstatt zu arbeiten. Und oben drauf kommt noch die Zeit für die Selbstorganisation der Abteilung und die Beteiligung der Mitarbeiter an der Weiterentwicklung der Firmenziele.“

Die Beobachtung des Team-Mitglieds mag subjektiv gefärbt sein, ist im Kern aber nicht von der Hand zu weisen. Dabei weiß ich, dass er und auch die meisten anderen Entwickler im Team dann am zufriedensten sind, wenn sie am Ende des Tages ihre Tasks fertig implementiert haben. Den Wert von offener, schneller und direkter Kommunikation stellt niemand mehr in Frage. Es gilt sogar als problematisches Sozialverhalten, sich gewünschter Kommunikation zu verweigern. Natürlich beantworten wir Fragen von Kollegen innerhalb und außerhalb des Teams „gerne mal schnell“. Selbstverständlich wollen wir über den Tellerrand schauen und interessieren uns dafür, wie sich die Firma und das Marktumfeld weiter entwickeln. Und die Notwendigkeit der Scrum-Events wird wohl niemand anzweifeln.

Einer der Gründe dafür, die Unsitte des Aufteilens der Arbeitszeit von Entwicklern auf mehrere Projekte zu beenden, war die Erkenntnis, dass „Rüstzeiten“ nicht nur die Produktivität von Fertigungsstraßen reduzieren, wenn die Maschinen für die Herstellung verschiedener Güter regelmäßig umgebaut werden müssen. Auch für intellektuelle Arbeit von Menschen, gerade für schwierige und kreative Tätigkeiten, die ein hohes Maß an Konzentration und „Hineindenken“ in eine fachliche Domäne oder z.B. einen Algorithmus erfordern, reduzieren häufige „Umschaltzeiten“ die Effizienz erheblich.

Das gilt nun allerdings nicht nur für das Umdenken zwischen verschiedenen Projekten, sondern auch dann, wenn es sich bei der Störung nur mal eben um eine kleine Frage, eine Diskussion oder eine Rücksprache handelt, zu der man sich im Daily verabredet hat.

Als mir aufgefallen ist, dass es immer wieder einmal vorkommt, dass Entwickler Tasks am späten Abend zu Hause oder am Wochenende erledigt haben, musste ich kritisch nachfragen, ob wir vielleicht an Overcommitment leiden und anmerken, dass doch der Feierabend der Regeneration dienen sollte. Antwort war, dass die zugesagten Stories eigentlich problemlos in einem Sprint zu schaffen sind, es aber bisweilen mehr Spaß macht und deutlich schneller geht Tasks allein zu Hause umzusetzen, wenn einen niemand anquatscht. Ehrlicherweise muss ich zugeben, dass es mir selbst nicht selten auch genauso geht. Das Dokumentieren der letzten Retro, die Vorbereitung eines Trainings oder das Schreiben eines Blog-Beitrags; das alles geht besser und schneller, wenn ich nicht im Team-Raum sitze und ein offenes Ohr für meine Kollegen habe. Früher haben wir Zeit mit Emails verplempert – die konnten aber leichter ignoriert werden, als heutzutage die Bitte um Face-to-Face Kommunikation.

Was also tun, damit Kommunikation und Zeit für’s Coden wieder in ein ausgewogenes Verhältnis kommen? Bekommen wir das hin, ohne dass nach Feierabend und am Wochenende gearbeitet werden muss?

Professor Cal Newport von der Georgetown University hat den Begriff „Deep Work“ geprägt. In seinem Buch „Rules for Focused Success in a Distracted World” beschreibt er den Wert konzentrierter, strukturierter, ungestörter, individueller Arbeit. In Zeiten der Reizüberflutung durch Push-Nachrichten, Slack-Channels und News-Tickern auf der einen Seite und dem Credo der Team-Arbeit auf der anderen Seite ist die Gelegenheit zu ebendieser Form der Produktivität selten geworden. Auch und gerade in typischen agilen Setups wie z.B. nach dem Scrum-Framework.

Meiner Ansicht nach lassen sich Newports Ideen aber sehr gut in agile Frameworks einbetten. Derzeit experimentiere ich mit meinen Scrum-Teams mit der „Deep Work“ Praktik folgendermaßen: Im morgendlichen Daily wird – wie eh und je – geklärt, welche Rücksprachen erforderlich sind, zu welchen Stories es noch Diskussionsbedarf gibt, welche Tasks am Besten im Pairing erledigt werden sollen usw. Gespräche, die nicht das gesamte Team interessieren, werden außerhalb des Team-Raums verabredet. Zusätzlich wird aber auch bewusst überlegt und entschieden, welche Tasks klar genug sind, um allein oder im Pairing ohne weitere Rücksprachen erledigt werden zu können. Wenn es genügend davon gibt, wird Zeit – möglichst Blöcke über mehrere Stunden – für Deep-Work Phasen eingeplant. Sollten sich unerwartet doch noch Fragen ergeben, so sollten diese nach der Deep-Work Zeit oder zumindest außerhalb des Team-Raums geklärt werden. Die Fähigkeit der Entwickler einschätzen zu können, ob es für einen Task noch Unklarheiten zu beseitigen gibt oder nicht, hat sich mittlerweile allerdings deutlich verbessert, so dass fast alle Deep-Work Tasks in den dafür geplanten Phasen effizient bearbeitet werden können. In Deep-Work Zeiten haben alle Team-Mitglieder die Freiheit, Slack, Skype und das Telefon auszuschalten. Soweit es die Räumlichkeiten hergeben, ziehen sich Pair-Programmer in Séparées zurück. Im Scrum-of-Scrums werden unsere geplanten Deep-Work Zeiten den anderen Teams mitgeteilt. Inzwischen werden diese Zeiträume von den anderen Teams respektiert, so dass die Tür unseres Team-Raums tatsächlich über längere Zeitabschnitte im Wesentlichen geschlossen bleiben kann.  Als Scrum-Master versuche ich Störungen kurz zu halten und erkläre Kollegen außerhalb des Teams, warum meine Entwickler gerade nicht auf Fragen im Chat reagieren. Derzeit bemühen wir uns im S-o-S darum, Deep-Work Zeiten Team-übergreifend zu koordinieren.

Natürlich bietet sich Deep-Work nicht in allen Phasen der Produktentstehung gleichermaßen an. Zum Beginn neuer Vorhaben, oder bei wesentlichen Richtungsänderungen durch sich plötzlich ändernde Marktbedingungen sind Unsicherheit und Kommunikationsbedarf groß. In derartigen Situationen wäre es äußerst schädlich, würde Deep-Work als Selbstzweck missbraucht! Notwendige Kommunikation hat in der täglichen Planung Priorität. Deep-Work ist eine gute Option, wenn Konsens darüber besteht, dass über einen Zeitabschnitt auf Austausch verzichtet werden kann.

Voraussetzungen für die erfolgreiche Anwendung der Deep-Work Praktik sind nach meiner Erfahrung sowohl eine gewisse Reife der Entwickler, als auch sehr gut entwickelte Skills im Requirements-Engineering. Mit „Reife“ meine ich hier die Fähigkeit, sich tatsächlich ohne soziale Kontrolle über einen längeren Zeitraum auf eine Sache konzentrieren zu können. Das kann geübt werden und ist nach Jahren des „Always-On“ in sozialen Netzwerken alles andere als selbstverständlich. Als Agile-Coach sollte man nicht enttäuscht sein, wenn zwischendurch auch mal die Sportnachrichten gecheckt werden – das passiert auch ohne Deep-Work und wenn ein hochkonzentrierter Gedankengang einmal in die Sackgasse geführt hat, kann es auch hilfreich sein, das Gehirn zwischendurch einmal zu entspannen. Sollte sich allerdings zeigen, dass Tasks in Deep-Work Phasen dauerhaft weniger effizient abgearbeitet werden, dann fehlt es vielleicht an Begeisterung für das Produkt oder es gibt Zweifel am Wert der zu liefernden Stories? Ist die Reife für Deep-Work weit gediehen, so lässt sie sich sogar hervorragend im Home-Office praktizieren. Arbeit im Home-Office bedeutet in diesem Fall dann nicht mehr permanente Erreichbarkeit im Chat und per Telefon um zu beweisen, dass tatsächlich gearbeitet wird, sondern das Vertrauen, dass die committedten Tasks konzentriert erledigt werden. Biorhythmen und familiäre Situationen können individuell sehr unterschiedlich sein; es gibt überhaupt keine Notwendigkeit dem einzelnen hereinzureden, zu welchen Tageszeiten Ruhezeiten sinnvoll sind und wann Deep-Work passt. Als Scrum-Master fühle ich mich dafür verantwortlich, darauf zu achten, dass sich einzelne Team-Mitglieder auch für Deep-Work in Heimarbeit nicht overcommitten – auch diesbezüglich ist eine gewisse Reife der Team-Mitglieder hilfreich.

Die zweite genannte Voraussetzung, gutes Methoden-Wissen und hohe Sensibilität für das Anforderungsmanagement, sollte beinahe selbsterklärend sein: Deep-Work funktioniert eben gerade dann, wenn für einen oder mehrere Tasks (nicht für ganze Epics oder das nächste Release!) kein weiterer Bedarf mehr für Abstimmung im Team oder mit Stakeholdern besteht. Knackig und präzise formulierte Stories und gut genug beschriebene Akzeptanzkriterien, dazu überzeugende Erklärungen des POs und eine konstruktive Diskussion der Stories im Backlog-Grooming und in Refinement-Sessions schaffen Potenzial für erfolgreiche Deep-Work Phasen. Die Relevanz der Story-Refinements in unserem Scrum-Framework und die Beteiligung aller Teammitglieder daran haben seit der Einführung von Deep-Work sogar noch weiter zugenommen. Es bleibt dabei, dass User-Stories eine Einladung zu weiterer Kommunikation sind – aber auch nicht zu unbegrenzter Kommunikation, sondern zur notwendigen Kommunikation, nach deren Abschluss Tasks dann konzentriert und effizient erledigt werden können. Und natürlich findet anschließend wieder Kommunikation statt, über das Ergebnis der in Deep-Work erreichten Ergebnisse.