Scrum Events nerven Entwickler? 3 Strategien für Scrum Master, sie zeitsparender zu gestalten – statt nur beliebter

„Ich verbringe so viel Zeit in Meetings, dass keine Zeit zum Coden bleibt.“

Vielleicht kommt dir diese Aussage eines Entwicklers aus einem deiner Teams auch bekannt vor. Meiner Erfahrung nach ist das Urteil weit verbreitet: Scrum besteht nur aus Meetings, es bleibt keine Zeit zum Arbeiten. Viele Scrum Master versuchen, die Entwickler davon zu überzeugen, dass Sprint-Retrospektiven wichtig für kontinuierliche Verbesserung sind, – oder die Events mit vielen bunten Klebezetteln und Legosteinen für die Entwickler beliebter zu machen. Diese Versuche machen die Sache leider auch nicht besser.

Schauen wir uns die Situation mal genauer an:

Das Spannungsfeld zwischen Entwicklern und Scrum Master

Wie sieht der Terminkalender eines Entwicklers aus?

Hier ein Beispiel:

• 9:00 – 9:30 Uhr: Daily Scrum
• 11:00 – 12:00 Uhr: Product-Backlog-Refinement
• 12:30 – 13:30 Uhr: Mittagspause
• 15:00 – 16:30 Uhr: Sprint-Retrospektive

Bei dem Terminkalender handelt es sich lediglich um ein Beispiel aus meiner Erfahrung der letzten 10 Jahre in Scrum Teams.

Hier einige Anmerkungen dazu:

• Vielleicht beginnt der Arbeitstag etwa gegen 8:30 Uhr mit dem Checken von E-Mails und dem Überprüfen von Commits vom Vortag.
• Der Arbeitstag endet etwa gegen 17:30 Uhr.
• Natürlich finden nicht an jedem Tag ein „Product-Backlog-Refinement“ oder eine „Sprint-Retrospektive“ statt. Es könnten auch Sprint-Review, Architektur-Meetings, 1:1-Gespräche mit dem Techlead, All-Hands-Company-Meetings usw. anstehen.

Was können wir daraus für den Arbeitstag eines Entwicklers schließen?

Von 8 Stunden reiner Arbeitszeit verbringt er etwa 3 Stunden mit Meetings und Abstimmungen und kann 5 Stunden fürs Entwickeln aufwenden. Wir kommen gleich noch einmal zum Terminkalender zurück, aber erstmal betrachten wir die Situation aus einem anderen Blickwinkel:

Von Entwicklern in Scrum Teams werden – implizit – drei Dinge erwartet:

• Fokus: Entwickler sollen sich auf die Arbeit konzentrieren. Nur so entsteht wirklich funktionierende Software.
• Zusammenarbeit: Entwickler sollen mit anderen Entwicklern und Fachexperten zusammenarbeiten, sich weiterbilden und ihr Wissen teilen.
• Transparenz: Entwickler sollen den Fortschritt ihrer Arbeit im Unternehmen sichtbar machen.

Jetzt fragst du dich bestimmt, worauf ich hinaus will? Dazu komme ich jetzt:

• Der „Fokus“ kommt von den Entwicklern selbst. Dafür wurden sie im Unternehmen angestellt.
• Der Punkt „Zusammenarbeit“ wird wahrscheinlich eher vom Scrum Master getrieben. Für bessere Qualität möchte er, dass die Entwickler regelmäßig gemeinsam über ihre Arbeitsweise reflektieren und Verbesserungen vornehmen.
• Die „Transparenz“ wird wahrscheinlich vom Scrum Master oder vom Product-Owner eingefordert.

Etwas überspitzt gesagt: Entwickler wollen sich auf ihre Arbeit konzentrieren. Scrum – in Person des Scrum Masters – lenkt sie davon ab und verlangt von ihnen mehr Zusammenarbeit und Transparenz.

Das im Hinterkopf. Wirf noch einmal einen Blick auf den Terminkalender. Ich denke, es ist nicht übertrieben, wenn ich sage: Scrum Events unterbrechen diesen Fokus. Und wer ist für die Unterbrechung verantwortlich?

Der Scrum Master — zumindest aus den Augen eines Entwicklers gesehen. 

Dies erzeugt ein ungutes Spannungsfeld zwischen Entwicklern und Scrum Mastern.

Was sind die Auswirkungen dieses Spannungsfeldes für Unternehmen?

Schätzungen zufolge gehen bis zu 40 % an Produktivität verloren, wenn wir zwischen Aufgaben hin- und herspringen.

In meinem „Professional Scrum Master“-Training zeige ich das immer anhand dieser Grafik.

Die Grafik stammt von Gerald Weinberg aus dem Buch „Quality Software Management, System Thinking“.

Wohlgemerkt handelt es sich beim Verlust durch Kontextwechsel um eine Schätzung. Diese deckt sich allerdings erstaunlich gut mit der Rückmeldung von Entwicklern. In einer Umfrage habe ich einmal die Entwickler im Team gefragt, was sie schätzen, wie lange es dauert, bis sie nach einer Unterbrechung beim Programmieren wieder im „Flow“ sind.

Ihre Antworten beliefen sich auf 15 bis 25 Minuten.

Betrachten wir noch einmal den Terminkalender eines Entwicklers von oben, dann erkennen wir, dass allein durch die Ablenkung von der Arbeit durch „Daily Scrum“, „Product-Backlog-Refinement“ und „Sprint-Retrospektive“ zwischen 45 und 75 Minuten verloren gehen. Oder etwas überspitzt formuliert:

Scrum kostet Entwickler 45 bis 55 Minuten ihrer Fokuszeit pro Tag.

Diese „Ablenkung“ macht sich natürlich auch in Euro bemerkbar. Für einen durchschnittlichen Entwickler können wir Kosten pro Stunde auf 125 Euro ansetzen. Für einen Entwickler an einem Tag mag dieser Betrag gering erscheinen. Aber rechnen wir das mal mit 10 Teammitgliedern und 220 Arbeitstagen im Jahr, dann belaufen sich die Kosten bereits auf 275.000 Euro.

Mit meiner Schätzung stehe ich nicht allein da:

Die Wirtschaftspsychologin Vera Starker hat diese versteckten Kosten kürzlich genauer untersucht.

Für die Untersuchung haben 637 in der Wissensarbeit tätige Personen aus 25 Unternehmen Tagebuch geführt. Auf einer Strichliste notierten sie drei Tage lang in einem bestimmten Zeitraum jede Unterbrechung und gaben die Daten in einer App ein. Das Forschungsteam hat die Aufzeichnungen anschließend genauer untersucht und verschiedene Ursachen für die Unterbrechungen ermittelt.

Ihre Erkenntnis:

„Das Gehirn braucht nach jeder Unterbrechung Zeit, bis es wieder auf die Aufgabe fokussiert ist. Diese Re-Fokussierungszeit kostet deutsche Unternehmen ca. 58 Mrd. Euro p. a.“

Ich denke, du stimmst mir zu, wenn ich zusammenfassend sage:

Die Auswirkungen des Spannungsfeldes zwischen Entwicklern und Scrum kosten Unternehmen am Ende bares Geld.

Wie sieht der Ausweg aus dieser kostspieligen Situation aus?

3 Strategien für entwicklerfreundlichere Scrum Events

Die Antwort lautet nicht:

Wir verzichten auf Scrum.

Der kurzfristige Gewinn durch mehr Konzentration auf die Arbeit verpufft sehr schnell langfristig, wenn wir bedenken, dass der Garant für langfristigen unternehmerischen Erfolg nicht mehr das Feature ist. Sondern mehr Innovation. Und Innovation wird eher durch Teamarbeit, Problemlösen und kontinuierliches Lernen ermöglicht. Darauf weist auch das World Economic Forum seit dem Jahr 2020 hin.

Und deshalb besteht der Ausweg darin, die Scrum Events wieder entwicklerfreundlicher zu machen.

Beim Schreiben dieses Satzes stellen sich mir gerade die Nackenhaare auf. Scrum ist doch von Entwicklern ins Leben gerufen worden?!?

Hier drei Strategien, wie ich bisher vorgegangen bin:

• „Time batching“: Was meine ich damit? Anstatt die Scrum Events über den Tag zu verteilen, lassen sich die Unterbrechungen reduzieren, wenn sie zu Blöcken zusammengefasst werden. Zum Beispiel: Der Vormittag ist immer meetingfrei, was natürlich auch bedeutet, dass das Daily Scrum am Nachmittag stattfindet. Aus der Sicht von Scrum ist das kein Problem – es heißt ja auch nicht „Morning Scrum“.
• Koordination und Teamarbeit stellen ein Spektrum dar: Es gibt zwei Extrema der Zusammenarbeit. Das eine ist die Koordination von Aufgaben, bei der jeder im Anschluss seinen Teil erledigt. Das andere ist Teamarbeit, bei der jeder im Team an denselben Aufgaben arbeitet. Die daraus resultierende Frage lautet: Wann sollte das Team als Team arbeiten, und wann sollte das Team die Arbeiten nur koordinieren? Findet das Refinement als Teamarbeit statt oder genügt es, wenn nur einige Entwickler daran teilnehmen und die Arbeiten im Sprint dann koordinieren?
• Events für die Entwickler gestalten und nicht für den Scrum Master: Klingt erstmal hart, ich weiß. Aber das Ziel der Retrospektive ist nicht, 90 Minuten in einem Raum zu sitzen und auf Klebezettel zu schreiben. Ihr Ziel ist es, eine Verbesserung für den nächsten Sprint zu identifizieren. Und versteh mich nicht falsch: Gute Retrospektiv-Formate helfen dabei ungemein. Aber manchmal reicht auch die Auswertung einer Feedback-Box, um in 15 Minuten zu einer Verbesserung zu kommen.

Diese Strategien für entwicklerfreundlichere Scrum Events scheinen auf den ersten Blick bestimmt ungewöhnlich. Und es braucht etwas Mut, sie umzusetzen. Aus meiner Erfahrung lohnt es sich. Als Scrum Master wollen wir ja die Entwickler mit Scrum bei ihrer Arbeit unterstützen – stimmt’s?

Ach, und entwicklerfreundlicher bedeutet auch nicht, die Scrum Events für die Entwickler beliebter zu machen.

Es bedeutet:

Den Entwicklern zu ermöglichen, sich den Großteil des Tages auf die Arbeit (Entwickeln und Scrum Events wohlgemerkt!) zu fokussieren, ohne dabei unterbrochen zu werden.