„Teilzeit-Scrum“ – sich aufteilen müssen zwischen der Arbeit im Scrum- oder gar Entwicklungsteam und anderen Arbeiten in der Organisation1 – ist m. E. eine der potentiell schädlichsten MeTooden, die aktuell en vogue sind. Zu dieser Einschätzung komme ich vor allem aus drei Gründen:
„Teilzeit-Scrum“ ist ein Impediment per se
Steht ein Mitglied des Scrum-Teams nur einen Teil seiner Arbeitszeit zur Verfügung, stellt dies per se ein Impediment dar2. Diesen Stein bewusst und womöglich gar von Anfang an in den Weg gerollt zu haben, ist nicht gerade ein Zeichen für eine glaubwürdige Festlegung auf das Framework – höchstwahrscheinlich haben wir an dieser Stelle eine klassische MeToode (vgl. hier), einen schlimmen Fall von Methoden-Frankensteining (vgl. hier) vor uns.
In Wirklichkeit könnte zudem dieses Impediment nur Ergebnis einer Problemverlagerung sein: Die Wahrscheinlichkeit ist groß, dass das eigentliche Problem „gefühlte oder reale mangelnde Kapazität in der Organisation“ gewesen sein dürfte – und nun zum Problem, gar zur „Accountability“ des selbstorganisierten Scrum-Teams und vor allem des Scrum-Masters gemacht wird. Ob es dadurch verschwindet, erscheint mir sehr fraglich. Sicher scheint mir aber: Das dürfte kein guter Start ins Projekt sein.
Konkurrierende Ziele vs. Commitment
Ob mit oder ohne Scrum: Arbeitet man in einem Projekt nur einen Teil seiner Arbeitszeit, hat man zwangsläufig mindestens um die eigene Arbeitszeit konkurrierende Ziele – eine Zielkonkurrenz, die der einzelne Mitarbeiter meist gar nicht auflösen kann und die gerade bei einem sehr engagierten Mitarbeiter fast automatisch zu unschönen inneren Konflikten führt. Die Betonung des Commitments – als explizierter Wert im Scrum Guide erwähnt und in der 2020-Version des Scrum Guides verstärkt gegenüber einzelnen Zielen und Artefakten – und deren m. E. häufige Überbetonung in der konkreten Implementierung verstärken diesen Konflikt.
Letztlich trägt die Organisation (bewusst oder aus Versehen) nur auf eine neue, andere Art ihre Kapazitätsprobleme auf dem Rücken der Menschen aus – nun jedoch gleichsam „geadelt“ als „agil“. Die Kapazitätsorientierung von Kanban wirkt auf mich an dieser Stelle deutlich menschlicher, Kanban für den Fall konkurrierender Ziele geeigneter (vgl. bspw. hier).
Die praktisch immer konkurrierenden Ziele in IT-Infrastruktur-Teams (Projektarbeit, Support und Wartung) sind übrigens einer der entscheidenden Gründe, warum mir Scrum für den IT-Infrastrukturbereich ungeeignet erscheint (vgl. hier)
Effizienz
Über Scrum wird oft gesagt, das Framework führe zu zu vielen [zu langen | überflüssigen] Meetings – dabei versucht der Scrum zugrundeliegende Lean-Thinking-Ansatz, jedwede Verschwendung zu vermeiden; jedes durch den Scrum Guide vorgesehene Meeting hat m. E. seinen spezifischen und relevanten Zweck und eine angemessene maximale Länge, alle Meetings sind zudem time-boxed. Die meisten Organisationen dürften ohne Scrum mehr Zeit in Meetings verbringen.
Was aber richtig ist: „Teilzeit-Scrum“ führt zu einem höheren relativen Anteil der Meeting-Zeit für den Einzelnen. Geht man von einem Ein-Monats-Sprint und den Vorschlägen des Scrum Guides für die maximale Länge der Events aus, liegt dieser Anteil pro Person bei etwas über 12 %. Steht ein Mitglied des Scrum-Teams dem Team nur zu 50 % zur Verfügung, steigt dieser Anteil auf 24 %3 – als effizient würde man das sicherlich nicht bezeichnen. Einzelne Mitarbeiter nun an einigen Meetings nicht teilnehmen zu lassen, mag vielleicht für das Daily Scrum noch möglich (wenn auch „regelwidrig“ – und bei lediglich 15 Minuten kaum hilfreich) sein, für die übrigen Meetings erscheint mir das extrem wenig sinnvoll – das Problem steigender Meeting-Zeit-Anteile ist also nicht wirklich lösbar, ohne die Methode massiv zu beschädigen.
Zusammenfassend kann man m. E: sagen: „Teilzeit-Scrum“ – Mitarbeiter nur einen Teil ihrer Arbeitszeit im Scrum-Team und am Produkt-Ziel arbeiten zu lassen – führt m. E. meist nur zur wenig zielführenden Verlagerung eines Kapazitätsproblems, stellt den Einzelnen vor durch ihn selbst unauflösbare Konflikte und reduziert die Effizienz. Letztlich handelt es sich vermutlich um eine MeToode und sehr sicher um ein ScrumBut4.
Footnotes:
- ↑ „Teilzeit-Scrum“ bezieht sich also keinesfalls auf Mitarbeiter in Teilzeit – auch das kann ein Impediment sein, damit umgehen zu können ist aber m. E. eine gesellschaftlich notwendige Aufgabe.
- ↑ Vgl. bspw. <https://www.scrum.org/forum/scrum-forum/5304/partially-allocated-team-members> (29.12.2020).
- ↑ ∅ 21 Tage/Monat respektive ∅ 168 Std./Monat. Max. 8 Std. Sprint Planning, 21 × 15 Minuten = 5,25 Std. Daily Scrum, max. 4 Std. Sprint Review, max. 3 Std. Sprint Retrospective – also 20,25 Stunden Meetings pro Monat. 20,25 Std./168 Std. ≈ 12 %, 20,25 Std./(168 Std. × 50 %) ≈ 24%.
- ↑ Vgl. bspw. <https://www.scrum.org/resources/what-scrumbut> (29.12.2020).