Remek ötlet: spóroljunk a Scrum Masteren!

Meg sem lehet számolni, hogy hányszor halljuk ezt az ötletet: nálunk majd az egyik fejlesztő lesz a Scrum Master 50%-ban és el van a dolog intézve. Volt ahol 10%-ot hallottunk. Probléma megoldva. Nem kell külön a Scrum Master felvételével, képzésével foglalkozni, a Scrum Masterünk fejleszteni is fog, a kecske is jóllakik és a káposzta is megmarad. Zseniális!

Valóban? Vajon a Scrum megalkotói miért tekintették különálló szerepkörnek a Scrum Mastert, nekik nem jutott eszükbe a fenti zseniális gondolat?

Matekozzunk egy kicsit. Vegyünk egy átlagosnak mondható, 7 fős csapatot. Adjunk hozzá egy 50%-ban fejlesztő / 50%-ban Scrum Master embert. A matek szerint csapat teljesítményét ezzel 0.5 emberrel, 7.5/7 =1.07 szeresére, azaz 7%-al növeltük.

De valóban kijön a matek? Két probléma van ezzel:

1. Ha valaki 50%-ban van kijelölve a feladatra, nem 50% eredményt fog elérni

 …hanem a fókuszvesztés és az állandó feladatváltogatás miatt jóval kevesebbet. Ráadásul a félkész feladat a legtöbbször nem 50% értéket képvisel, hanem semmit. Hiszen nincs kész. Azaz, szinte garantált, hogy ha ez az ember valóban 50%-nyi kritikus feladatot kap, ő lesz a leglassúbb, nem segíteni, hanem hátráltatni fogja a csapatot. Kinek kell ilyenkor közbeavatkozni? Hát a Scrum Masternek! Annak az embernek, aki épp piszkosul nem ér rá, hiszen épp ő az, akit segíteni kellene. Hiába az lenne a feladata, hogy növelje a teljesítményt, valójában egyrészt nem lesz ideje ezzel foglalkozni, másrészt saját fejlesztői teljesítménye messze el fog maradni a várttól.

2. A Scrum Master elsődleges feladata a csapat teljesítményének folyamatos növelése.

A fenti példa 7%-a pedig igen soványka eredmény egy Scrum Mastertől, aki 50% mellett jó, ha az alapvető adminisztratív feladatokat és facilitálást el tudja látni, sem a csapat, sem saját maga fejlesztésére nem marad ideje. Amikor Jeff Sutherland, a Scrum egyik kitalálója a “The Art of Doing Twice the Work in Half the Time” címet adta a Scrumot ismertető könyvének, ez nem csak marketingfogás volt. Komolyan is gondolta. Elméletben akár négyszeres, azaz 300%-al több teljesítményt lehet a Scrum-mal elérni (a gyakorlatban az épp a fentiekhez hasonló “megoldjuk okosban” megoldások miatt sajnos ritka), de ennél nagyobb ugrásra is van példa.

Számoljunk újra egy kicsit. A fenti példában ha a 7 ember fejenként 100 egység, azaz összesen 700 egység értéket termel, ha ehhez egy katalizátor embert adunk, aki ugyan értéket közvetlenül nem termel, de 15%-al emeli a csapat teljesítményét, az már 7*115 azaz 805 egység értéket jelent, nagyobb emelkedést, mint egy új fejlesztő hozzáadása, már megérte. Egy közepesen jó Scrum Master pedig ennél sokkal többre képes, még a csak részben sikeres agilis transzformációktól is elvárható a tipikusan 20%-50%-os teljesítménynövekedés. (Forrás: Scaled Agile Inc., SAFe, Why do Businesses Need SAFe?, 2018).

Akkor spóroljunk a Scrum Masteren?

Mielőtt tehát meghozzuk azt a döntést, hogy a Scrum Masteren spórolunk, érdemes megfontolni a fentieket. Kis csapatoknál lehet, hogy valóban felesleges a teljes munkaidejű Scrum Master, de már egy közepes méretű csapatnál is levágjuk az aranytojást tojó tyúkot, ha nem engedjük, hogy a Scrum Master a csapat teljesítményének növekedésére koncentráljon. Ráadásul sokszor látjuk, hogy a csapat legjobb fejlesztőjét nevezik ki Scrum Masternek, kirántva a lába alól a talajt fejlesztés terén, miközben nem lesz ideje és energiája a csapat katalizátoraként működni.

Gondoljátok át, nálatok is végez a Scrum Master fejlesztési munkát? Ha igen, jut ideje a csapat fejlesztésére, vagy csak titkári/titkárnői feladatokat lát el? Ha nem, akkor valóban a csapat katalizátoraként működik, érti, hogy ez a fő feladata?