V prejšnjih dveh člankih smo spoznali Tuckmanov model razvoja teamov in kasneje, kako vodja, glede na doseženo stopnjo razvoja, prilagaja svoj način usmerjanja teama.
V tem prispevku si bomo na kratko ogledali še kako Scrum Master izobraževalni fokus usmerja znotraj posamezne iteracije v drugem delu tega članka pa, kako teami v Scaled Agile okolju medsebojno delijo znanje in izkušnje. Training
Po Scrum Guide 2020 je Scrum Master (citiram):
“Odgovoren za učinkovitost Scrum Teama. To dosega tako, da omogoča Scrum Teamu, da znotraj Scrum ogrodja izboljšuje svoje prakse.“
S stališča posredovanja znanja, zgoraj napisano ne pomeni le, da Scrum Master člane teama izobrazi o dobrih Agilnih praksah in orodjih, ki jih team pri tem uporablja. Pomeni tudi da člane vzpodbuja v teamsko in med teamsko izmenjavo pomembnih informacij in pridobljenega znanja.
POUČEVANJE
Pomembno orodje pri doseganju cilja učinkovitosti, je poučevanje v katerikoli od spodaj naštetih različic.
Training
Klasično, strukturirano poučevanje po predpripravljenem kurikulumu. Ta način poučevanja Scrum Master običajno uporabi:
- Na začetku Agilne transformacije, ko je potrebno deležnike masovno izobraziti o izbranem Agilnem frameworku.
- Ob sprejemu novih teamskih članov. Neglede na to ali so že prej delali v istem Agilnem frameworku. Implementacije se namreč med organizacijami, pa tudi znotraj posamezne organizacije, lahko zelo razlikujejo.
- Ko sodelujoče seznanja z načini usmerjanja Agilnih ceremonij. Še posebno Sprint Retrospektive, ki je precej strukturiran dogodek. Cilj je, da vodenje ceremonij team s časom prevzame sam (self-managed team).
V Scaled Agile okolju, frontalno izobraževanje, teami prakticirajo tudi medsebojno. Primer bi bila med-teamska delavnica s predstavitvijo nove verzije APIja, ki ga bojo v naslednji iteraciji morali začeti uporabljati vsi teami ali pa predstavitev nove platforme za regresijsko testiranje. Takšno delavnico skličejo in izvajajo razvojniki sami. Več o tem v drugem delu članka.
Coaching
Je inštruiranje na določeno temo, ki se kasneje, glede na interes in potrebe razširi na sorodne teme in poglobi. Primer coachinga bi bilo poučevanje Product Ownerja o prioritizacijskih shemah in svetovanje pri izboru najprimernejše.
Coaching je manj strukturiran od treninga in se prilagaja sprotnim potrebam. Lahko je individualni ali skupinski. Zadnji del članka bomo posvetili ravno tej obliki poučevanja/inštruiranja.
Mentoring
Mentorstvo je bolj profesionalni odnos, kot pa namensko usmerjena dejavnost. Teme izbira mentoriranec, izkušeni član pa mu po potrebi svetuje in pomaga. Manjši del mentorstva je tudi osmotska komunikacija.
Opomba: V Sloveniji je izraz mentor na precej slabem glasu. Večina se nas še spomni profesorjev na faksu, ki so bili naši “mentorji” in smo jim v seminarskih in diplomskih morali pisati zahvale samo zato, da so nam zamenjali zaporedje dveh odstavkov. V tujini mentorstvo jemljejo resneje. Mentorji na Ameriških univerzah so s strani študentov tudi ocenjevani in posledično nagrajevani – ali pa odpuščeni.
Training je torej frontalen, običajno na začetku neke aktivnosti. Mentorstvo sprotno, po potrebi. Coaching pa…
COACHING PODROBNEJE
Cilj coachinga s stališča Scrum Mastra je kontinuirano izboljševanje procesov in pomoč teamu pri premagovanju ovir.
Scrum Master coaching izvaja na dveh nivojih: teamskem in individualnem.
Coaching teama je izrazitejši na začetku in koncu Sprinta, saj se takrat izvajajo skupinske ceremonije kot npr. Sprint Planning, Sprint Review in Sprint Retrospective. Takrat je teamu potrebno svetovati glede namena in učinkovitega izvajanja le teh.
Med samo iteracijo je čas za individualni coaching. Člani teama bodo običajno prosili za pomoč pri odstranjevanju določene prepreke ali pa se na Scrum Mastra obrnili s pritožbo ali predlogom. Individualni coaching ohranja zaupnost med Scrum Mastrom in članom teama. Scrum Master mora čez čas preveriti, ali je bil izpostavljeni problem rešen.
Interpretiral bom Lisso Adkins, znano Scrum trenerko, ki je opisala štiri pomembne značilnosti Scrum Master coachinga:
- Teamu ali posamezniku ne ponuja rešitve. Četudi jo pozna. S pomočjo sugestij in usmerjanja naj se s članom ali skupino srečajo na “pol poti”. Četudi manj optimalna rešitev, ki jo bo team predlagal sam, bo izvedena učinkoviteje kot “idealna” rešitev, ki bi jo na primer prelagal Scrum Master. Če team zamišljeno rešitev vidi kot svojo, se bo njeni realizaciji posvetil bolj zavzeto, kot če bi mu bila le ta delegirana od zunaj.
- Ohranimo zaupnost. To velja tako za individualni kot skupinski coaching.
- Sodelujmo z managerji glede spremenjenih metrik ocenjevanja in nagrajevanja članov teamov, če so ti še vedno vpeti v hierarhično strukturo organizacije. Cilje funkcionalnih managerjev (ki niso del Agilnega teama) je potrebno uskladiti s cilji zaradi katerega so bili teami formirani – mnogo lažje reči kot narediti.
- Imejmo pozitiven odnos do vseh deležnikov. Neglede na osebno mnenje. V vsakem človeku se skriva nekaj dragocenega in enkratnega.
SCRUM MASTER vs. AGILE COACH
Mnogo organizacij poleg Scrum Mastrov angažira tudi Agile Coache. V čem je razlika in ali v resnici obstaja?
Percepcija teh dveh funkcij je v organizacijah običajno podobna temu:
SCRUM MASTER:
- Je DEL enega ali več Scrum teamov. To mu/ji omogoča dober vpogled v dinamiko in razvoj posameznega teama in njegovo usmerjanje v smer dobrih Scrum/Agilnih praks ter povečevanja učinkovitosti dela.
- Dolgoročnejša funkcija. Zato so Scrum Mastri običajno zaposleni v sami organizaciji.
AGILE COACH:
- Deluje na enterprise nivoju. Istočasno podpira veliko teamov in nima globokega vpogleda v dinamiko individualnih teamov.
- Vzpostavlja sistem koordinacije med teami v organizaciji.
- Razširja Agilno zavedanje in podpira Agilno transformacijo organizacije.
- 20-30% več plačan od Scrum Mastra (če je zaposlen v organizaciji). Če je pogodbenik omejitve navzgor ni.
- Smatrano za kratkotrajnejšo vlogo. Zato je Agile Coach pogosto zunanji pogodbenik.
Po napisanem bi lahko sklepali, da realnost Agile trga narekuje, da je relacija med Agile Coach in Scrum Mastrom podobna relaciji software arhitekta in razvojnika. Ali je res tako?
Citiram najnovejši Scrum Guide:
“The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide. They do this by helping everyone understand Scrum theory and practice, both within the Scrum Team and the organization.”
Ločnica med Agile Coach in Scrum Master je v veliki meri umetna. Scrum Master ne more delovati samo na teamskem nivoju, ampak se njegove naloge raztezajo čez celotno organizacijo. Scrum Master torej pravtako izvaja coaching. Ali je to pretežno na teamskem ali enterprise nivoju, pa je odvisno od njegovega znanja in izkušenj. Želja je seveda, da vsi Scrum Mastri slej kot prej postanejo sposobni delovati na vseh nivojih organizacije. To je še posebej pomembno, ko organizacija implementira enega od Scaled Agile frameworkov. Če se Scrum Mastri takrat preimenujejo v Agile Coache, je to za stanje Agila v organizaciji irelevantno. Bolje pa zveni v CVju.
KAJ PA RAZVOJNIKI IN PRODUCT OWNER?
Reality-check
Agilni razvoj temelji na konstantni izmenjavi informacij in znanja med deležniki. Učinkovito orodje, ki preprečuje kreiranje izoliranih “silosov znanja” je nagrajevanje navzgor. To pomeni, da se razvojni team za dosežke nagrajuje kot celota. Posamezniki se za individualni doprinos v Agilnih organizacijah ne nagrajujejo. Iz tega razloga so člani teama zainteresirani za deljenje svojega znanja, ker s tem povečujejo produktivnost celotnega teama.
Vprašanje, ki se na tečajih običajno pojavi na tej točki je: “Kaj pa če imamo v teamu člana, ki se šlepa na račun ostalih?“
Odgovor na to vprašanje je preprost, ampak zahteven za realizacijo, ker zahteva spremembo miselnosti znotraj organizacije. Če se smatramo za Agilno organizacijo, pomeni, da so naši razvojni teami samo organizirajoči. Takšni teami sami odločajo o svojem članstvu. Novi člani se teamu lahko pridružijo iz same organizacije (organizacijska mobilnost), ali pa jih teami samoiniciativno zaposlijo z zunanjega trga (mimo ali s podporo HR).
Predno HR začnejo kričati, da “to pač ne gre na ta način“, saj novi razvojniki morajo biti predvideni v letnem planu – kar je v praksi irelevantno, če bo novi član kreiral dobiček – se vprašajmo naslednje: Ali je teamom etično jemati pravico izbiranja lastnih članov, če jih nagrajujemo kot celoto?
In tako se vrnemo na člana teama, ki se “šlepa”. Če je temu tako, ga ostali člani samo organizirajočega teama imajo pravico odsloviti. Navsezadnje zaradi njega/nje trpi njihova lastna kompenzacija. Če je bil član potegnjen iz organizacije, se lahko vrne na prejšnje delovno mesto, če pa je bil zaposlen za potrebe projekta, se ga odpusti.
V Scaled Agile okolju kjer več teamov vzporedno razvija isti produkt, se nagrajevanje izvaja še nivo višje – na nivoju skupine teamov. Ker se spontana komunikacija običajno odvija znotraj posameznega teama, se je v takšnih okoljih potrebno še posebej potruditi, da se znanje in informacije kar se da učinkovito razširjajo med skupino teamov. Poznamo množico orodij, ki nam pri tem lahko pomagajo.
(DELNI) ZAKLJUČEK
Ko sem ga pisal, je članek postajal vse daljši in daljši, tako da sem se ga odločil razdeliti na dva dela. V naslednjem delu bomo spoznali deset pristopov (orodij) s katerimi si teami v Scaled Agile okolju učinkovito delijo znanje in informacije.
