Ki lenne a legalkalmasabb személy a Scrum Master pozíció betölrtésére? Ez a Scrum bevezetések egyik első kérdése. A jó hír, hogy bárkiből lehet jó Scrum Master, akinek van első kézből származó tapasztalata arról, hogy milyen egy fejlesztő csapatban dolgozni. Ha ez megvan, akkor már „csak” némi vezetői készségre lesz szüksége. A rossz hír, hogy ennél több szabályt nem lehet mondani. A csapatnak és a Scrum Masternek összhangban kell lennie és ez az összhang rengeteg tényezőn múlik. Éppen ezért semmiféle általános receptet nem ismerek arra, hogy ki legyen a Scrum Master, aki majd a Ti csapatotoknál beválik. Amit első körben el kell dönteni, hogy főállású Scrum Mastert válasszunk, vagy a fejlesztő csapat egy tagjára bízzuk ezt a feladatot? Mindkét megoldás előnyeit és hátrányait megnézzük.
Legyen a fejlesztő csapat tagja?
Miért ne lehetne? Előbb azonban tisztázzuk, hogy kikből áll a fejlesztő csapat. A Scrum mindenkit a fejlesztő csapat tagjának tekint, aki tevékenyen részt vesz a produktum előállításában és felelősséget vállal annak minőségéért.
- Szoftverfejlesztők
- Tesztelők
- Üzleti elemzők
- Technical writer
- Stb.
Tehát nem csak szoftverfejlesztőkről beszélünk, amikor a Scrum fejlesztő csapatot emlegetjük.
Miért jó, ha a Scrum Master a fejlesztő csapat tagja?
Számtalan előnye van annak, ha olyan Scrum Mastert választunk, aki a fejlesztő csapatnak is tagja. Még több, ha ő egyben szoftverfejlesztő is.
- Könnyen elfogadják. Nyilvánvaló, hogy az az ember aki nap-mint-nap együtt dolgozik a csapat többi tagjával könnyebben megérti magát velük mint az, aki egy teljesen más szerepkörben dolgozik.
- Első kézből érti a problémákat. Mivel állandó tapasztalata van a projekt napi kihívásairól, ezért nem kell neki elmagyarázni, hogy mi nyomasztja, mi hátráltatja a csapatot. Ez segíti abban, hogy gyorsan felsimerje a legnagyobb problémákat.
- Képben van a projekttel. Könnyen megértheti magát a Product Ownerrel, mivel nagyon jól tudja, hogy milyen terméket fejlesztenek.
- Ismeri a kód minőségét. Az agilis fejlesztés kritikus eleme az átlátható, jó minőségű kód. Bármilyen jó is a Scrum Master, ha a csapat nem fordít kellő figyelmet a kód minőségére, akkor előbb vagy utóbb súlyos problémákkal kell szembenézniük. Senkinek sincs több esélye arra, hogy ezt időben észrevegye, mint egy szoftverfejlesztőnek.
- Nem hoz be „vízfejet”. Ha a fejlesztő csapat tagja látja el a Scrum Master feladatokat, akkor nincs szükség új ember felvételére és egy újabb „vízfej” eltartására. Kis cégek Scrum csapatainál ez döntő érv lehet.
Látszik, hogy megdönthetetlennek tűnő érvek szólnak amelett, hogy a legjobb Scrum Master szoftverfejlesztő és egyben a fejlesztő csapat tagja is. Vagy mégsem?
Miért ne legyen a fejlesztő csapat tagja?
Minden előnye ellenére, a fejlesztő csapat tagjaként is dolgozó Scrum Master az egyik legnagyobb kihívással néz szembe. Ez pedig a szerepkonfliktus.
Ha fejlesztőként dolgozom, akkor állandóan mérlegelnem kell, hogy mivel teszek jót, vagy mivel ártok kevesebbet a csapatnak. Képzeljük el a következő helyzetet.
A csapatom egy nagyon szorosra sikerült sprint végéhez közeledik. Már több korábbi sprintet is elbuktunk és nagyon jót tenne a morálnak, ha ezt sikerrel zárnánk. Mivel én vagyok az egyik legjobb fejlesztő, ezért nagyon oda kellene tennem magam, hogy a maradék feladatokat befejezzük a sprint végéig. Van viszont két probléma…
- A csapatom két tagja valamin csúnyán összekapott és ez érezhetően rombolja a morált és az együttműködést. Ezt a konfliktus fel kellene oldanom, amihez sok időre és türelemre lehet szükségem.
- A product owner a mai napig nem készítette elő product backlogot a következő sprinttervezésre, ezért vele is foglalkoznom kellene.
- De mi lesz akkor a jelenlegi sprinttel? Mi lesz, ha pont miattam nem sikerül megint teljesítenünk a sprint célkitűzéseit? Mi lesz, ha nem kezelem a problémákat és ezzel végleg hagyom tönkremenni a csapat morálját?
Kevés ennél nehezebb helyzetet tudok elképzelni. (Láttam is és át is éltem már hasonlót.) Bárhogy dönt, mindenképpen komoly konfliktusba kerülhet a csapattal és súlyos következményei lehetnek a döntésének. Hogy mi a teendő ilyen esetben, arról is hamarosan beszélünk, de előbb nézzük meg, hogy mi a helyzet a főállású Scrum Masterrel?
Főállású Scrum Master
Nem véletlenül határoztak meg külön szerepkört a Scrum alkotói. Feltehetően a főállású Scrum Master lesz a megoldás. Nézzük, hogy miért nem ennyire egyszerű a helyzet.
- Extra költségként tekintenek rá. Tényleg szükség van egy 5-6 fős fejlesztő csapat mellé egy főállású „menedzserre”? Ezzel a kérdéssel találkozom a leggyakrabban és nem is feltétlenül könnyű megindokolni a választ. Különösen kis cégek számára elfogadhatatlan ez a helyzet.
- Menedzserként kezd viselkedni. Ezt a hibát én is elkövettem és bár nem feltétlenül lehetetleníti el a működést, ma már nagyon figyelek rá, hogy lehetőleg elkerüljük a hasonló helyzeteket. A coaching egyik alapszabálya, hogy az értékelés és a fejlesztés két különálló tevékenység. Coachként nagyon figyelek rá, hogy ne kelljen értékelnem azokat az embereket, akik fejlesztésére szerződtem. Amint értékelném az embereket, csökkenne a bizalmuk felém és máris rejtegetni kezdenék előlem a problémákat. Mivel a Scrum Master feladata a csapat fejlesztése, ezért nagyon óvakodnia kell attól, hogy a szó hagyományos értelmében vett „menedzserré” váljon.
- Kilóg a csapatból. Ha egy ember nem vesz részt tevékenyen a termék előállításában, akkor könnyen kivűlrekedhet a csapaton. A helyzetétől és korábbi pozíciójától függően általában két mód valamelyikével reagál erre. Vagy a vezetés felé kezd húzni és „menedzser” lesz, vagy éppen ellenkezőleg, megpróbálja kiszolgálni a csapatot és alárendelt szerepet vesz fel. A második talán rosszabb. Van egy harmadik reakció is, ami mindkét előzőnél rosszabb. Ez pedig a csapatból történő kivonulás és látszattevékenység folytatása.
Mindezek ellenére sok jel mutat arra, hogy a főállású Scrum Master a jó irány. Ilyenkor nagy a kísértés, hogy egy főállású Scrum Master több csapatot is vigyen egyszerre, ezzel csökkentve az adminisztrációs költségeket. Bár ezt sokan ellenzik, van olyan eset, amikor van létjogosultsága ennek a modellnek is. És ez sajnos elég gyakori: ha nem jut minden csapatra egy alkalmas Scrum Master. Egy lelkes és tehetséges Scrum Master képes kettő, maximum három csapatot is támogatni, főleg ha azok egy terméken dolgoznak. Bár nem ideális felállás, de sokkal jobb annál, mintha egy csapat igazi Scrum Master nélkül maradna.
A legjobb szerepköri elrendezés
Van ideális szerepköri elrendezés? Ha innen nézem legyen főállású, ha onnan nézem, akkor legyen a fejlesztő csapat tagja. Hogyan valósítsuk ezt meg? Induljunk ki abból, hogy a Scrum Master a fejlesztő csapat tagja. Méghozzá olyan tagja, akit a csapat azzal bízott meg, hogy működtesse a Scrum kultúrát a fejlesztő csapat és a product owner együttműködésében. A Scrum Master, a fejlesztő csapat és a product owner együtt a SCRUM CSAPAT. A Scrum Masterre mindenki tekintsen úgy, hogy…
- Képes lenne valamilyen fejlesztő szerepkört (szoftverfejlesztő, tesztelő, elemző stb.) betölteni a csapaton belül, de közösen úgy döntöttünk, hogy ennél fontosabb feladatot kap: összehangolja a csapat munkáját és védi a csapat egységét és munkavégzését.
- Ennek megfelelően, ha nincs más dolga, akkor tevékenyen beszáll a produktum előállításába és fejlesztői (értsd: szoftverfejlesztő, tesztelő, elemző stb.) munkát végez. De erre soha nem építünk, mint csapat.
- A Scrum Master szerepkörből adódó feladatai fontosabbak, mint a fejlesztő szerepkörből adódó feladatai. Ha a másodikat szorítja háttérbe, akkor a sprint sikerét veszélyezteti, de a csapatnak lesz esélye a felépülésre. Ha az elsőt hanyagolja el, akkor az egész Scrum csapat széteshet és a felépülés esélyét is elveszíti.
- Scrum Masterként esetenként többet találkozik a menedzsmenttel mint mások, de ettől nem válik a tradicionális menedzsment tagjává, önállóan nem értékeli a csapat tagjait.
Egy utolsó tanács a fejlesztőből lett Scrum Master számára. Scrum Masterként nem a fejlesztő csapat, hanem a teljes Scrum csapat érdekeit kell szem előtt tartania. Különösen multinacionális vállalatoknál, ahol a product owner külföldön van, hajlamosak vagyunk őt bűnbaknak kikiáltani minden problémáért. Scrum Masterként minden erőnkkel, minden esetben a Scrum csapat kettészakadása ellen kell küzdenünk!