Maker‘s schedule vs. Manager‘s schedule

Das Team ächzt. Gerade mal etwas Zeit freigeschaufelt, da kommt schon wieder ein Workshop-Termin des Scrum Masters rein - zusätzlich zur Retrospektive, die ja auch in den nächsten Tagen noch ansteht! Retrospektive bedeutet Sprintende, Sprintende bedeutet, dass womöglich wiedermal Überstunden am Schreibtisch gemacht werden müssen, um diese letzten vermaledeiten User Stories noch zum guten Abschluss zu bringen

 

In diesem Artikel möchte ich das Konzept „Maker‘s Schedule vs. Manager‘s Schedule“ vorstellen. Viele andere haben das sicher schon vor mir getan, trotzdem habe ich individuelle Erfahrungen für den Umgang damit gesammelt, die ich gerne hier teilen möchte.

Paul Graham bereicherte die Welt mit diesem neuen Blickwinkel auf die unterschiedlichen Kalender zweier unterschiedlicher Rollen in einem Unternehmen und die daraus entstehenden Herausforderungen /1/.

 

Unterschiedliche Arbeitsweisen - unterschiedliche Kalenderfüllung

Es geht um den Konflikt, dass Manager vornehmlich Meetings abhalten, sich mit Personen austauschen müssen, Erwartungen einsammeln, sich mit verschiedenen Personen(gruppen) abstimmen, Informationen einholen etc. pp.

Ihr Tag ist geprägt von vielen Gesprächen mit unterschiedlichen Personen.

Dies wäre der Alptraum für Entwickler:innen, wo diese doch nichts mehr benötigen als Ruhe, um in ihren Code abtauchen und einen versteckten Fehler finden oder die zu entwickelnde Software weiter voranbringen zu können, sich über mehrere Stunden am Stück fokussieren zu können, ohne immer wieder aus ihren Gedanken gerissen zu werden.

Von den Kosten des Hin- und Herspringens

Hier kommt dann auch noch der Effekt der „costs of task switching“ dazu, den Gerald Weinberg fand /2/: Seine Untersuchungen haben gezeigt, dass je mehr unterschiedliche simultane Aufgaben jemand bewältigen muss, desto unproduktiver er oder sie wird, da das eigene Gehirn mit zunehmender „Projektanzahl“ immer mehr Zeit zur mentalen Umrüstung benötigt. Immer wieder Faden-neu-Aufnehmen und Sich-wieder-in-das-andere-setting-Eindenken frisst Zeit, die produktiv verwendet werden könnte, wenn man an einer einzigen Aufgabe arbeiten könnte und dort in einen Arbeitsfluss käme. Der aktuellen Forschung zufolge arbeitet jemand mit fünf verschiedenen Aufgaben, die jeden Tag jeweils weiterbearbeitet werden sollen, nur noch zu etwa 20% produktiv.

Bisschen wenig, oder?

Kampf der Kalender

Zurück zu den Terminkalendern: Aus oben genanntem Grund haben Entwickler:innen, die „maker“ des Produktes, in der Regel am liebsten einen Terminkalender, bei dem jeder Tag aus einem einzigen großen Arbeitsblock besteht, nur unterbrochen durch vielleicht das Mittagessen.

 (fiktives selbstgebasteltes Beispiel)

 

Scrum Master, Agile Coaches und ähnliche folgen definitiv dem Manager-Kalender: Ein Meeting am anderen, ständige Abstimmungen, Austausche, Entscheidungen, Brainstormings, Verbesserungs- und andere Workshops:

 

 

(anonymisiertes [fast] reales Beispiel)

 

Sie sind verantwortlich für die Erhöhung der Performance ihrer Teams durch agile Arbeitsweisen, für die Verbesserung der Zusammenarbeit bis über die Grenzen ihrer eigenen Teams hinaus, für die Verbreitung von Agilität bis ganz nach oben und in die hinterste staubige Ecke des Unternehmens (so das Unternehmen es denn damit tatsächlich ernst meint…).

Ein Tag in ihrem Terminkalender setzt sich typischerweise aus vielen kleinen unterschiedlichen Scheibchen zusammen. Zwischendurch sind sie sogar auch immer mal wieder eine Art „maker“: dann z. B., wenn sie den nächsten Workshop vorbereiten - sofern sie kein Schema F aus der Schublade ziehen können.

Leichter Interessenskonflikt...

In der Arena der Reibungsverluste stehen sich nun also die „Maker“, die Ruhe und Frieden für Fokussierung und Produktfortschritt brauchen, und die „Manager“, welche Lieferfähigkeit von Teams erhöhen helfen, Informationsflüsse in Unternehmen mitgestalten und Hindernisse beseitigen sollen, also mit eher vielen Leuten sprechen, gegenüber.

Das führt mich zu der Überlegung, dass es in meiner Spezies, derjenigen der „Scrum Master, Agile Coaches und ähnlichen“ (siehe oben), manchmal auch darum zu gehen scheint, seine Existenzberechtigung durch hohes Aktivitätsniveau zu untermauern. Ein Scrum Master, von dem man nie was hört und sieht, macht sich verdächtig. Beim Eifer, sich im Unternehmen einzubringen, sollte man unbedingt darauf achten, diejenigen, die für die Produktentwicklung zuständig sind - und damit zukünftiges Geld in der Unternehmenskasse sichern, das u. a. auch für Scrum Master-Gehälter ausgegeben wird - nicht zu sehr vom Arbeiten abzuhalten.

Über ständige Zeitnot und das generelle adäquate Vorgehen

„If you want to save money, potentially deliver early and deliver value sooner - help your colleagues to focus on one thing and one thing only“ (Steve Trapps) /3/

Natürlich ist die Welt nicht so einfach, und die Schubladen, hübsch schwarz oder weiß, klemmen hier etwas. Warum haben Entwickler:innen in manchen Unternehmen z. B. nicht mal Zeit, um Dinge ausgiebig zu testen oder an einem zyklisch wiederkehrenden Verbesserungsworkshop, auch Retrospektive genannt (und nicht selten schon auf eine läppische Stunde heruntergekürzt), teilzunehmen? Brauchen sie die Erkenntnisse daraus nicht? Kann es dann sein, dass für das, was sie erstellen, agile Arbeitsweisen gar nicht das Richtige sind, weil man sich gar nicht im Nebel und auf Neuland vortasten und deswegen regelmäßig aus seinen neuen Erfahrungen lernen muss? Oder könnte es vielleicht sein, dass die Leute in den niederen Rängen vor Arbeit kaum aus den Augen gucken können, weil weiter oben im Unternehmen - im Konzept der „Flight Levels“ auch „Portfolio-Ebene“ genannt /4/ - irgendwas faul ist und dort eine Initiative nach der anderen parallel gestartet wird, bis das System einen Kolbenfresser erleidet?

Einige Ideen für eine Annäherung

Was tun nun aber, um wenigstens ein bisschen Entlastung zu schaffen?

Ich hatte einmal ein Team, dem ich dieses Konzept von den unterschiedlichen Terminkalendern präsentierte. Nachdem es gedanklich verarbeitet war, begannen wir, unseren Team-Kalender umzuräumen. Am Schluss folgten an einem Tag - auf Vorschlag von 2-3 Teammitgliedern und ohne Widerspruch der anderen - Daily, Refinement und Planning direkt hintereinander. Ein großer Block, aber danach war erst mal wieder Ruhe, und alle wussten, dass sie in der nächsten Zeit länger würden „terminfrei“ arbeiten können.

Auf einer Seite der Scrum.org beispielsweise gibt es weitere Anregungen /5/.

An einer der Wurzeln zu arbeiten beginnen

Weiterhin durfte ich einmal Teil einer Bereichsinitiative sein, bei der wir rollenübergreifend an Empfehlungen für bessere Meetings arbeiteten. Das "besser" bezog sich auch unmittelbar auf die Anzahl der zu besuchenden Meetings pro Person.

Zu den erarbeiteten Empfehlungen gehörten folgende Bausteine:

- Agenda versenden (eigentlich selbstverständlich, aber…)

- Nur diejenigen einladen, die wirklich für die Erarbeitung der Inhalte notwendig sind, alle anderen weglassen (auch nicht in Kopie setzen); Erarbeitetes kann später asynchron geteilt werden

- wenn man merkt, dass man beim Meeting nichts beitragen kann, den Saal schnellstmöglich wieder verlassen…

- Moderation und timeboxing sicherstellen

Eine Hochrechnung wirkt besser als bloße Empfehlungen

Wir bekamen sogar gemittelte Gehaltszahlen mitgeteilt und errechneten anhand eines fiktiven Beispiels, wie schnell die Kosten in astronomische Höhen schnellen können, ohne dass irgendein Wert dabei geliefert wird. Mehr noch, viele teilen ihre Aufmerksamkeit dann auf, was im Falle der „Maker“ zu unkalkulierbaren Fehlern im Produkt wegen mangelnder Konzentration führen kann. Diese Kosten blieben in unserem Beispiel eine Dunkelziffer.

Die Bereichsleitung stand voll hinter uns, was dem Publikum hoffentlich den Mut gab, die Empfehlungen tatsächlich selbst umzusetzen: nicht willenlos und unhinterfragt in Meetings tapern, nur weil man eingeladen wurde, und zu einem Meeting, bei dem genau zwei Wissensträger benötigt werden, nicht den halben Bereich einladen, „nur zur Sicherheit“.

Blocker im Kalender, um das eigene Team zu schützen (?)

Einmal traf ich auch einen Agile Coach, der großartigerweise ganz offen im Kreise von seinesgleichen (also uns, den anderen Coaches, die ja auch potenziell kommen und sein Team mit irgendwas von der Arbeit abhalten wollen könnten) bekannte, dass sie, er und sein Team, ein oder zwei größere Blocker in ihrem Teamkalender hätten, die den Teammitgliedern als Schutzschild dienten, um dahinter in Ruhe Produktentwicklung betreiben zu können. Flapsig kam von ihm die kreative Empfehlung, solche Blocker z. B. mit etwas wie „lateraler Strategieworkshop“ zu betiteln. In diesem Moment kam in mir die Idee auf, dass, wenn wir uns alle gegenüber den anderen Teams so offenlegen würden, wir die Chance hätten, in unserem gesamten Bereich die störungsfreien Arbeitsblöcke zu synchronisieren.

 

Leider kam der Stein während meiner Zeit dort nicht ins Rollen, obwohl ich diesen Felsbrocken mehrfach anzuschieben versucht habe: zu viele zeitliche Abhängigkeiten bei den einzelnen Teams („aber wir können mittwochs nicht, weil da…“), zu wenig Elan, zu viel erwarteter Synchronisierungsaufwand, vielleicht zu theoretisch und kein greifbarer Nutzen spürbar und noch einige Gründe mehr.

Sowas fädelt man wahrscheinlich am besten gleich beim Aufbau agiler Strukturen ein. Eventuell wird es oft nicht gleich zu Beginn umgesetzt, einfach weil keiner daran denkt (?). Vielleicht erhalte ich in meinem Leben noch mal die Chance, das auszuprobieren.

Quellen:

/1/ Originaltext: https://www.paulgraham.com/makersschedule.html

/2/ Weiterführende Information inkl. Grafik z. B. unter https://unito.io/blog/context-switching-definition/ und https://hbr.org/2022/08/how-much-time-and-energy-do-we-waste-toggling-between-applications; Originalwerk von G. Weinberg: "Quality Software Management: Systems Thinking" (Jahr der Erstveröffentlichung: 1991, Dorset House)

/3/ Steve Trapps: https://www.scrum.org/resources/blog/financial-cost-task-switching

/4/ Flight Levels: z. B. K. Leopold-Video mit auswählbaren Bausteinen: https://m.youtube.com/watch?v=30SnExerX7Y

/5/ https://www.scrum.org/resources/blog/makers-schedule-managers-schedule