Warum „Teilzeit-Scrum“ m. E. nur das Problem verlagert, Zielkonflikte verursacht und nicht effizient ist

„Teil­zeit-Scrum“ – sich auf­tei­len müs­sen zwi­schen der Arbeit im Scrum- oder gar Ent­wick­lungs­team und ande­ren Arbei­ten in der Organisation​1 – ist m. E. eine der poten­ti­ell schäd­lichs­ten MeToo­den, die aktu­ell en vogue sind. Zu die­ser Ein­schät­zung kom­me ich vor allem aus drei Gründen:

„Teilzeit-Scrum“ ist ein Impediment per se

Steht ein Mit­glied des Scrum-Teams nur einen Teil sei­ner Arbeits­zeit zur Ver­fü­gung, stellt dies per se ein Impe­di­ment dar​2. Die­sen Stein bewusst und womög­lich gar von Anfang an in den Weg gerollt zu haben, ist nicht gera­de ein Zei­chen für eine glaub­wür­di­ge Fest­le­gung auf das Frame­work – höchst­wahr­schein­lich haben wir an die­ser Stel­le eine klas­si­sche MeToo­de (vgl. hier), einen schlim­men Fall von Metho­den-Fran­ken­stei­ning (vgl. hier) vor uns. 

In Wirk­lich­keit könn­te zudem die­ses Impe­di­ment nur Ergeb­nis einer Pro­blem­ver­la­ge­rung sein: Die Wahr­schein­lich­keit ist groß, dass das eigent­li­che Pro­blem „gefühl­te oder rea­le man­geln­de Kapa­zi­tät in der Orga­ni­sa­ti­on“ gewe­sen sein dürf­te – und nun zum Pro­blem, gar zur „Accoun­ta­bi­li­ty“ des selbst­or­ga­ni­sier­ten Scrum-Teams und vor allem des Scrum-Mas­ters gemacht wird. Ob es dadurch ver­schwin­det, erscheint mir sehr frag­lich. Sicher scheint mir aber: Das dürf­te kein guter Start ins Pro­jekt sein.

Konkurrierende Ziele vs. Commitment

Ob mit oder ohne Scrum: Arbei­tet man in einem Pro­jekt nur einen Teil sei­ner Arbeits­zeit, hat man zwangs­läu­fig min­des­tens um die eige­ne Arbeits­zeit kon­kur­rie­ren­de Zie­le – eine Ziel­kon­kur­renz, die der ein­zel­ne Mit­ar­bei­ter meist gar nicht auf­lö­sen kann und die gera­de bei einem sehr enga­gier­ten Mit­ar­bei­ter fast auto­ma­tisch zu unschö­nen inne­ren Kon­flik­ten führt. Die Beto­nung des Com­mit­ments – als expli­zier­ter Wert im Scrum Gui­de erwähnt und in der 2020-Ver­si­on des Scrum Gui­des ver­stärkt gegen­über ein­zel­nen Zie­len und Arte­fak­ten – und deren m. E. häu­fi­ge Über­be­to­nung in der kon­kre­ten Imple­men­tie­rung ver­stär­ken die­sen Konflikt. 

"Teilzeit-Scrum" – Zielkonflikte und Commitment

Letzt­lich trägt die Orga­ni­sa­ti­on (bewusst oder aus Ver­se­hen) nur auf eine neue, ande­re Art ihre Kapa­zi­täts­pro­ble­me auf dem Rücken der Men­schen aus – nun jedoch gleich­sam „geadelt“ als „agil“. Die Kapa­zi­täts­ori­en­tie­rung von Kan­ban wirkt auf mich an die­ser Stel­le deut­lich mensch­li­cher, Kan­ban für den Fall kon­kur­rie­ren­der Zie­le geeig­ne­ter (vgl. bspw. hier).

Die prak­tisch immer kon­kur­rie­ren­den Zie­le in IT-Infra­struk­tur-Teams (Pro­jekt­ar­beit, Sup­port und War­tung) sind übri­gens einer der ent­schei­den­den Grün­de, war­um mir Scrum für den IT-Infra­struk­tur­be­reich unge­eig­net erscheint (vgl. hier)

Effizienz

Über Scrum wird oft gesagt, das Frame­work füh­re zu zu vie­len [zu lan­gen | über­flüs­si­gen] Mee­tings – dabei ver­sucht der Scrum zugrun­de­lie­gen­de Lean-Thin­king-Ansatz, jed­we­de Ver­schwen­dung zu ver­mei­den; jedes durch den Scrum Gui­de vor­ge­se­he­ne Mee­ting hat m. E. sei­nen spe­zi­fi­schen und rele­van­ten Zweck und eine ange­mes­se­ne maxi­ma­le Län­ge, alle Mee­tings sind zudem time-boxed. Die meis­ten Orga­ni­sa­tio­nen dürf­ten ohne Scrum mehr Zeit in Mee­tings verbringen.

Was aber rich­tig ist: „Teil­zeit-Scrum“ führt zu einem höhe­ren rela­ti­ven Anteil der Mee­ting-Zeit für den Ein­zel­nen. Geht man von einem Ein-Monats-Sprint und den Vor­schlä­gen des Scrum Gui­des für die maxi­ma­le Län­ge der Events aus, liegt die­ser Anteil pro Per­son bei etwas über 12 %. Steht ein Mit­glied des Scrum-Teams dem Team nur zu 50 % zur Ver­fü­gung, steigt die­ser Anteil auf 24 %​3 – als effi­zi­ent wür­de man das sicher­lich nicht bezeich­nen. Ein­zel­ne Mit­ar­bei­ter nun an eini­gen Mee­tings nicht teil­neh­men zu las­sen, mag viel­leicht für das Dai­ly Scrum noch mög­lich (wenn auch „regel­wid­rig“ – und bei ledig­lich 15 Minu­ten kaum hilf­reich) sein, für die übri­gen Mee­tings erscheint mir das extrem wenig sinn­voll – das Pro­blem stei­gen­der Mee­ting-Zeit-Antei­le ist also nicht wirk­lich lös­bar, ohne die Metho­de mas­siv zu beschädigen.

Zusam­men­fas­send kann man m. E: sagen: „Teil­zeit-Scrum“ – Mit­ar­bei­ter nur einen Teil ihrer Arbeits­zeit im Scrum-Team und am Pro­dukt-Ziel arbei­ten zu las­sen – führt m. E. meist nur zur wenig ziel­füh­ren­den Ver­la­ge­rung eines Kapa­zi­täts­pro­blems, stellt den Ein­zel­nen vor durch ihn selbst unauf­lös­ba­re Kon­flik­te und redu­ziert die Effi­zi­enz. Letzt­lich han­delt es sich ver­mut­lich um eine MeToo­de und sehr sicher um ein Scrum­But4.

Fuß­no­ten:

  1.  „Teil­zeit-Scrum“ bezieht sich also kei­nes­falls auf Mit­ar­bei­ter in Teil­zeit – auch das kann ein Impe­di­ment sein, damit umge­hen zu kön­nen ist aber m. E. eine gesell­schaft­lich not­wen­di­ge Aufgabe.
  2.  Vgl. bspw. <https://​www​.scrum​.org/​f​o​r​u​m​/​s​c​r​u​m​-​f​o​r​u​m​/​5​3​0​4​/​p​a​r​t​i​a​l​l​y​-​a​l​l​o​c​a​t​e​d​-​t​e​am-members> (29.12.2020).
  3.  ∅ 21 Tage/​Monat respek­ti­ve ∅ 168 Std./Monat. Max. 8 Std. Sprint Plan­ning, 21 × 15 Minu­ten = 5,25 Std. Dai­ly Scrum, max. 4 Std. Sprint Review, max. 3 Std. Sprint Retro­spec­ti­ve – also 20,25 Stun­den Mee­tings pro Monat. 20,25 Std./168 Std. ≈ 12 %, 20,25 Std./(168 Std. × 50 %) ≈ 24%.
  4.  Vgl. bspw. <https://​www​.scrum​.org/​r​e​s​o​u​r​c​e​s​/​w​h​a​t-scrumbut> (29.12.2020).

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*