Inovatyvus Projektų Valdymas

Kuomet organizacija veikia Scrum metodo principu, įprasta darbo diena prasideda kasdieniu Scrum narių susitikimu. Idealiu atveju, susitikimai visada vyksta toje pačioje vietoje, tuo pačiu laiku, griežtai limituojant posėdžio trukmę – vieno susitikimo laikas neturi viršyti penkiolikos minučių.

Posėdyje dalyvauja visi Scrum nariai: Produkto Šeimininkas, Scrum Meistras ir Komanda. Visi kiti su projektu susiję asmenys, tačiau nepriklausantys Scrum (pvz.: pardavimų vadybininkai), taip pat gali dalyvauti susitikime, su sąlyga, kad jie užims tik klausytojų pozicijas. Ši sąlyga susitikimus daro kryptingai orientuotus į sklandų Scrum narių tarpusavio bendradarbiavimą ir apsaugo nuo išorinių trikdžių.

Kadangi, posėdžio laikas yra labai ribotas, jo metu nesprendžiami nesklandumai ir neaptariami iškilę klausimai. Komandos narys, susidūręs su problema gali konsultuotis individualiai su Scrum Meistru iš karto po susitikimo ar kitu patogiu laiku. Tai padeda išvengti nereikalingų diskusijų tarp nesuinteresuotų asmenų ir sutaupyti laiko.

Kasdienio susirinkimo metu, Komandos nariai orientuojasi tik į tris klausimus:

1. Ką nuveikiau vakar?
2. Ką nuveiksiu šiandien?
3. Kaip man sekasi tvarkytis su užduotimis?

Sutelkdami dėmesį į ką tik atliktus ir ketinamus atlikti darbus, Komandos nariai vieni su kitais dalinasi savo kuriama verte bei išlaiko atvirus darbinius santykius, reikalingus tvariam bendradarbiavimui ir vieningam tikslo siekimui. Nepaisant to, kad susitikimuose dalyvauja Produkto Šeimininkas ir Scrum Meistras, tai nėra standartiniai posėdžiai, kurių tikslas – priversti darbuotojus atsiskaityti už atliktus darbus. Atvirkščiai, tai yra susirinkimas, kuriame Komandos nariai prisiima įsipareigojimus vienas kitam ir dalinasi pasiekimais. Pavyzdžiui, jei programuotojas sako, kad šiandien baigs duomenų saugojimo modulį, tuomet kiti Komandos nariai žino, kad ši užduotis rytoj bus padaryta ir programuotojas galės pereiti prie naujos.

Nuoseklus darbo eigos stebėjimas padeda Komandai pamatuoti savo atliekamo darbo vertę, suvokti savo vykdomų atsakomybių svarbą ir nebijoti prisiimti naujų įsipareigojimų.

Dauguma organizacijų, propaguojančių Scrum, atlieka kasdienį Scrum susitikimą standartiškai, kiekvienam Komandos nariui atsakant į tris klausimus. Tačiau galima alternatyva – aptarti kiekvieną užduočių sąrašo punktą iš eilės. Tokiu būdu, visi Komandos nariai gauna progą pasisakyti apie kiekvieną punktą atskirai.

Tam, kad nereiktų mokytis iš savų klaidų, pateikiame penkias dažniausiai daromas klaidas, kurios gadina kasdienių Scrum susitikimų kokybę ir primygtinai siūlome jų nekartoti.

5 kasdienių Scrum susitikimų klaidos:

1. Informacijos kolekcionavimas – neverta rinkti ir užsirašinėti kasdienių susitikimų metu girdimos informacijos. Sisteminti gautą informaciją ir daryti išvadas yra Scrum Meistro darbas, o Komandos nariai turėtų koncentruotis į užduotis ir būdus, kaip jas atlikti geriausiai.
2. Nuostata, kad kasdieniai susitikimai reikalingi tik Scrum Meistrui – jei, vienas Komandos narys kalba Scrum Meistrui, o kiti landžioja mobiliuosiuose telefonuose, tada, tai nėra bendradarbiavimu grindžiama aplinka ir Scrum Meistro pareiga tai ištaisyti. Kasdienių susitikimų paskirtis – komunikavimo ir bendro darbo principu eiti vieno tikslo link, todėl kolegos turi būti suinteresuoti išklausyti vienas kitą.
3. Kasdienis susitikimas nėra tas pats, kas planavimo susitikimas – jei Scrum Meistras pradeda kasdienį susitikimą pranešdamas Komandai apie naujus reikalavimus ir klausdamas ar šie sugebės juos pritaikyti savo darbe, tuomet prasideda diskusija ir kasdienis posėdis virsta planavimo susitikimu. Esant neatidėliotinai būtinybei aptarti šiuos reikalavimus, siūloma tai padaryti po kasdienio susitikimo, skiriant kelias papildomas minutes, nemaišant visko į vieną.
4. Kasdienis susitikimas neturi pavirsti į technines diskusijas – kai kurios Komandos pasakodamos apie savo atliekamas užduotis išsiplečia iki detalių. Nariai kalba apie techninę užduoties atlikimo pusę, o tai iššaukia nereikalingus kolegų klausimus, kurie sunaudoja daug laiko ir duoda mažai naudos.
5. Scrum lentos lokalizavimas vienoje patalpoje, o kasdienių susitikimų vykdymas – kitoje – lentos naudojimas suteikia galimybę perteikti reikiamą informaciją vizualiai ir padeda nepasimesti susitikimo eigoje. Kuomet lentos nėra toje pačioje patalpoje, kur vyksta susitikimas, Scrum Meistrai naudoja elektroninius laiškus, o tai nėra nei patogu, nei protinga, nes atima daug laiko ir išskaido Komandos dėmesį.

Siekiant maksimaliai tenkinančių rezultatų ir didžiausio produktyvumo, kasdienių susitikimų metu Scrum nariai turi koncentruotis į esminius tris klausimus, nekalbėti apie kliūtis bei rizikas ir nesiūlyti būdų kaip jas išspręsti, nes tai padarys Scrum Meistras, tam skirtu laiku. Pagrindinis komandos tikslas turėtų būti – pristatyti savo atliekamas užduotis, išklausyti kolegų ir pasiruošti naujai produktyviai dienai. 

Nepaisant to, kad internete gausu straipsnių Scrum metodikos taikymo organizacijose tematika, pradedantys vartotojai ne visada randa aiškius atsakymus į jiems rūpimus klausimus. Tam, kad Scrum diegimas organizacijoje būtų sklandus, parengėme trumpus ir aiškius atsakymus į dažniausiai sutinkamus klausimus.    

Ar Scrum yra Agile?

Scrum yra Agile šeimos narys. Scrum metodika vadovaujasi visomis Agile vertybėmis ir principais, kurių laikantis, kuriami maksimalios vertės produktai ar paslaugos. Scrum metodikos paskirtis – padidinti darbo našumą ir sumažinti laiko sąnaudas. Scrum procesai padeda organizacijoms prisitaikyti prie greitai besikeičiančios aplinkos ir pagaminti maksimalios vertės produktus.

Kada verta rinktis Scrum?

Scrum naudojimas organizacijoje yra naudingas, jei:

• Projekto pradžioje nėra aiškios visos detalės;
• Egzistuoja pakeitimų rizika;
• Yra poreikis nuolat stebėti atlikto darbo vertę;
• Produkto kūrimui pasitelkiamas kūrybiškumas.

Scrum privalumai:

• Ankstyva vertės realizacija;
• Mažesnė vėlavimo rizika;
• Mažesnė produkto kūrimo kaina;
• Didesnė motyvacija darbuotojams;
• Propaguojamas bendradarbiavimas;
• Kokybiškesnis galutinis produktas ir didesnis klientų pasitenkinimas;
• Suderinamumas tarp IT ir verslo padalinių.

Kokio dydžio turėtų būti Scrum komanda?

Vieningo atsakymo į šį klausimą nėra. Viena vertus, kuo didesnė Komanda, tuo daugiau darbo ji gali atlikti, tačiau, kita vertus, didelės Komandos valdymas sąlygoja daugiau komplikacijų, dėl sudėtingesnio užduočių planavimo ir koordinavimo. Optimaliu Komandos dydžiu laikomas narių skaičius – nuo trijų, iki devynių, neskaičiuojant Produkto Šeimininko ir Scrum Meistro.

Kodėl Produkto Šeimininkas tuo pačiu negali atlikti ir Scrum Meistro rolės?

Produkto Šeimininko paskirtis yra atstovauti verslo interesus komandai, o Scrum Meistro paskirtis – atstovauti komandos interesus verslui. Kai vienas asmuo atstovauja abiem interesų grupėms, jis natūraliai linksta į vieną arba į kitą pusę, o tai yra neteisinga kažkurios iš jų atžvilgiu.

Kaip ir kuo remiantis Komandos nariai skirstosi užduotis?

Teoriškai, Scrum Komanda pati organizuoja savo darbą, bendradarbiavimo principu. Tol, kol Komandos nariai geba įsiklausyti vienas į kitą, bendrai priimti sprendimus bei planuoti darbą, pavienių užduočių skirstymasis nėra būtinas. Praktiškai, daugumos Komandų nariai specializuojasi skirtingose veiklos srityse, todėl užduočių skirstymas gali būti naudingas. Tai leidžia Komandai tiksliai identifikuoti užduotis ir sklandžiai atlikti savo funkcijas. Skirstymas turėtų būti preliminarus, lankstus ir lengvai prisitaikantis prie galimų pokyčių.

Kas yra produkto užduočių sąrašas (Backlog)?

Produkto užduočių sąrašas yra prioretizuotas darbų planas, apibrėžiantis kokios užduotys turi būti atliktos vienos iteracijos metu. Sąrašas sudaromas trumpų istorijų pagrindu, kurių tikslas –  kuo tiksliau atspindėti produkto funkcionalumo reikalavimus.

Kaip turi būti tvarkomas produkto užduočių sąrašas?

Produkto užduočių sąrašas turi būti tvarkomas tokiu būdu, kad didžiausios vertės, kruopščiai detalizuotos istorijos būtų patalpintos produkto užduočių sąrašo viršuje, o mažiau detalių turinčios – apačioje. Produkto Šeimininko atsakomybė yra paruošti tokį užduočių sąrašą, kuris kurtų didžiausią vertę verslui. Svarbu atkreipti dėmesį, kad šiuolaikinėje rinkoje vyrauja staigių ir nenuspėjamų pokyčių tikimybė, kuri reikalauja lankstumo. Atsižvelgiant į pokyčius istorijos gali būti koreguojamos bei keičiama jų prioretizavimo tvarka.

Kas yra iteracijos planavimo susitikimas ir kam jis skirtas?

Iteracijos planavimo susitikimas skirtas savarankiškai dirbančios Komandos bendradarbiavimo su Produkto Šeimininku užtikrinimui. Susitikimo tikslas – aptarti artėjančios iteracijos planus ir preliminariai nuspręsti kokie darbai turi būti padaryti.

Susitikimas skaidomas į dvi dalis:

1. Teorinė dalis, kurios metu sprendžiama KĄ reikia padaryti. Komanda aptaria savo gebėjimus ir galimybes bei analizuoja naujų galimybių prieinamumą. Komanda peržiūri Produkto Šeimininko parengtą užduočių sąrašą ir išsikelia būsimos iteracijos darbų tikslus.
2. Praktinė dalis, kurios metu sprendžiama KAIP tuos tikslus įgyvendinti. Aptariama kas atliks kurias užduotis, kaip jos paveiks projektą, kaip sumažinti galimas rizikas ir kaip bendru darbu pasiekti maksimalią vertę.

Kas yra istorijų taškai (story points) ir kiek jų reikia surinkti per vieną iteraciją (sprintą)?

Istorijų taškai yra preliminari matavimo priemonė, apibrėžianti kiek pastangų reikės įdėti vienos istorijos įgyvendinimui. Paprastai tariant, tai yra numeris, kuris leidžia Komandai numatyti ar bus sunku realizuoti istoriją ar ne. Dažniausiai naudojama istorijos taškų skalė yra nuo 1 iki 100. Jei viena istorija verta 20 taškų, o kita 40, tuomet galima numatyti, kad antrosios įgyvendinimui prireiks dvigubai daugiau laiko. Tam, kad vertinant būtų pasiektas maksimalus tikslumas, vertinimo procese turi dalyvauti visi Komandos nariai. Kiek taškų reikia surinkti vienos iteracijos metu, priklauso nuo kiekvienos Komandos poreikių, projekto apimties ir galimybių individualiai, todėl svarbu išsikelti bendrą tikslą ir siekti jo kolektyviai.

Kam skirtas greičio (velocity) matavimas ir kaip jis veikia?

Greičio metrika yra pagrindinė darbo vertės matavimo priemonė Scrum. Ji nusako kokį darbo kiekį Komanda gali atlikti vienos iteracijos metu parodo jos produktyvumą. Greitis apskaičiuojamas iteracijos pabaigoje susumavus visus atliktų vartotojo istorijų taškus.

Kada Scrum nėra tinkamiausias pasirinkimas?

Scrum metodas geriausiai veikia nedidelėse Komandose, kurių nariai siekia bendro tikslo dirbdami kartu. Scrum taikymas gali būti komplikuotas, jei Komandos narių skaičius viršija dešimties žmonių ribą ir, jei kiekvienas iš jų atlieka labai skirtingas, tarpusavyje nesusijusias funkcijas. Vis tiek esant poreikiui taikyti Scrum, rekomenduojama skirstyti Komandą į mažesnius pogrupius ir ugdyti bendradarbiavimo dvasią juose.

Scrum – projektų valdymui ir produktų kūrimui naudojama sistema. Pirminė Scrum paskirtis buvo palengvinti programinės įrangos kūrimo procesus, tačiau šiuo metu, sistema plačiai naudojama ir kitose srityse. Iš pirmo žvilgsnio, gali pasirodyti, kad Scrum pritaikymas kitų veiklų sritims kelia nemažai problemų, tačiau, iš tiesų, Scrum naudojimas gana paprastas. Didžiausiu iššūkiu tampa ne eksploatacija, o įdiegimas, kuomet tradicinį projektų valdymą propagavusi įmonė pradeda dirbti naujų metodų principu.

Ar įmonės perėjimas prie Scrum metodo taikymo savo darbe bus sėkmingas, didžiąją dalimi priklauso nuo to, kokia yra įmonės struktūra. Mažą bendruomenę, kurioje vyrauja tvarūs tarpusavio santykiai, suvaldyti bus gana lengva, kai tuo tarpu, daugybę filialų turinčią milžinę – pakankamai didelis iššūkis.

Kol komanda įpras organizuoti savo darbą pagal Scrum metodiką, rekomenduojama veikti koncentruotai, vienoje grupėje, be papildomų pogrupių. Tai neleis komandai blaškytis ir padės koncentruotis ties atliekamu darbu visu pajėgumu. Pradžioje gali iškilti nemažai nesklandumų, todėl vertėtų rinktis mažos rizikos projektus.

Scrum metodikos diegimas įmonėje pareikalaus tam tikrų pertvarkymų, tokių kaip pareigybių bei darbo pobūdžio pakeitimai, naujų atsakomybių prisiėmimas ir senųjų pamiršimas. Siekiant sklandaus Scrum technikos įgyvendinimo, svarbu neskubėti ir stengtis suprasti Scrum taisykles. Tai padaryti padės septyni žingsniai sėkmingo Scrum naudojimo link.

Pirmas žingsnis – išsiaiškinti detales apie būsimą projektą ir išnagrinėti kliento poreikius. Šį darbą Scrum metodikoje atlieka Produkto Šeimininkas, kuriuo dažniausiai tampa žmogus,   gebantis prisiimti atsakomybę ir stropiai ją vykdyti. Produkto šeimininkas yra vienintelis asmuo, atsakingas už produkto užduočių sąrašą – ką, kada ir kam reikia padaryti, todėl jis turi pasirūpinti, kad produkto užduočių sąrašas visada būtų paruoštas, patalpintas matomoje vietoje ir visiems prieinamas.

Antras žingsnis – išsirinkti Scrum Meistrą. Tai daryti reiktų labai atsakingai, nes šis žmogus lydės komandą kiekviename žingsnyje, mokys teisingai taikyti Scrum metodiką ir padės spręsti nesklandumus. Scrum Meistro tikslas – užtikrinti komandos darbo našumą, pakreipiant komandą reikiama linkme ir padedant teisingai pasiskirstyti darbo krūvį. Scrum Meistrą galima traktuoti kaip laivo kapitoną, sujungiantį komandą, kurios kiekvieno nario užduotis yra nepriekaištingai atlikti savo darbą, kai, tuo tarpu, Scrum Meistro – fokusuotis ties projekto visuma.

Trečias žingsnis – paruošti užduočių sąrašą. Šį darbą padaro Produkto Šeimininkas, kuris paskirsto užduotis prioritetų tvarka, tam, kad komanda pirmiausia atliktų svarbiausius darbus ir tik tada pereitų prie mažiau svarbių. Užduočių sąrašas Scrum metodikoje yra pateikiamas istorijų pagrindu – trumpais aprašymais, papasakotais per kliento perspektyvą. Tarkim “aš noriu, kad mygtukai A ir B atliktų funkciją C”. Tuomet programuotojai – komandos nariai – atliekantys užduotis, imasi šio noro įgyvendinimo.

Ketvirtas žingsnis – suplanuoti įvykį (sprintą) ir jį įgyvendinti. Scrum metodikoje, projektas skaidomas į įvykius, leidžiančius atlikti darbus dalimis. Projekto planavimui skirto susitikimo metu, Produkto Šeimininkas pristato užduotis ir kartu su komandos nariais aptaria pirmojo įvykio eigą. Scrum metodikoje susitikimai yra kasdienis reiškinys, padedantis išlaikyti tvarų komandinį darbą ir efektyviai valdyti projektą. Kasdienių susitikimų metu aptariama kas buvo nuveikta iki šiol, identifikuojami ateinančios dienos darbai bei pristatomi iškilę nesklandumai ir ieškomi būdai jiems išspręsti.

Penktas žingsnis – peržiūrėti įgyvendintą įvykį (sprintą). Šiame etape dalyvauja ne tik Produkto Šeimininkas, Scrum Meistras ir komanda, bet ir klientai. Peržiūros metu pristatomi nuveikti darbai, aptariami pasiekimai ir įvertinama pažanga. Čia svarbiausia – kliento poreikių įgyvendinimas.

Šeštas žingsnis – testuoti bandomąją projekto versiją. Kadangi dalis darbų jau baigti ir projektas įgavęs pagreitį, laikas praktiniam patikrinimui. Šiame žingsnyje akivaizdžiai matomas progresas ir galima objektyviai įvertinti darbo rezultatus.

Septintas žingsnis – įvykių retrospektyva. Paskutinis projekto vystymo etapas, kurio metu, Produkto Šeimininkas, Scrum Meistras ir komanda aptaria kaip galėtų pagerinti savo darbą. Tai padaryti padeda “pradėti – baigti – tęsti” metodas. Kiekvienas Scrum komandos narys pasidalina savo įžvalgomis ką naujo būtų galima įnešti, kad darbas vyktų sklandžiau, ką reiktų baigti daryti, kad būtų išvengta nesklandumų ir kokios technikos vertos tęstinio naudojimo naujuose projektuose.

Scrum sistemos paskirtis – užtikrinti, kad darbo procesas veiktų sklandžiai, kad darbo laikas būtų išnaudojamas efektyviai ir, kad kliento poreikiai būtų išpildyti maksimaliai kaip tik įmanoma. Taigi, kodėl įmonėms verta taikyti Scrum savo kasdienybėje? Todėl, kad šis metodas padeda pamatyti, patikrinti bei pritaikyti geriausius sprendimus, ugdo komandinę dvasią ir skatina nuolat peržiūrėti savo veiklos rezultatus, mokytis iš klaidų ir tobulėti.

Kaip įprastai veikiančiai organizacijai nepasimesti Scrum metodo rolėse ir teisingai perorganizuoti savo darbuotojų atsakomybės? Svarbu įsisąmoninti, kad Scrum metodo veikla, paremta darnia trijų rolių komunikacija. Čia egzistuoja Produkto Šeimininkas, Scrum Meistras ir Darbų Vykdymo komanda. Šios rolės išskaidė įprastas Projektų Vadovo funkcijas ir griežtai suskirstė atsakomybes. Kiekviena rolė turi savo nuosavą aiškiai apibrėžtų darbų rinkinį, kurių vykdymas užtikrina projekto sėkmę.

Produkto Šeimininko, Scrum Meistro ir Darbų Vykdymo Komandos paskirtis

Produkto Šeimininkas iš esmės yra atsakingas už projektą. Pagrindinė jo funkcija – užtikrinti, kad darbų sąrašas sutaptų su verslo reikalavimais ir kliento poreikiais. Darbų Vykdymo Komanda atlieka visas užduotis, reikalingas kokybiškam projekto vystymui, o Scrum Meistras, bendradarbiaudamas su Darbų Vykdymo Komanda ir Produkto Šeimininku, kuria palankią aplinką efektyviam produkto vystymui.

Scrum Meistras iš arčiau

Scrum Meistro paskirtis – užtikrinti, kad Darbų Vykdymo Komandos nariai laikosi Scrum metodikos taisyklių ir principų. Atsiradus nesklandumams, Scrum Meistras motyvuoja komandą bei pataria jai kaip susitvarkyti su nesėkme ir grįžti prie darbų, išnaudojant mažiausiai resursų. Jis nuolat stebi kaip veikia Scrum procesai ir dalinasi idėjomis kaip jų veikimą padaryti sklandesniu, moko komandą saviorganizacijos bei padeda jai tikslingai planuoti savo laiką. Scrum meistras skatina betarpišką komandos narių bendradarbiavimą, ugdo jų pasitikėjimą vienas kitu ir atsako už individualaus darbo transformavimą į kolektyvinį rezultatą.

Projektų Vadovas iš arčiau

Projektų Vadovo pozicija apima labai platų atsakomybių spektrą. Pradedant planavimu bei  organizavimu ir baigiant vadovavimu bei kontroliavimu. Planavimo procesas, dėl dinamiškos aplinkos, dažniausiai trunka visą projekto laiką ir atsako į klausimus “kas turi būti padaryta?” “kada turi būti padaryta?” bei “kas tai padarys?”. Projektų Vadovas susiduria su tokiais uždaviniais, kaip projekto plano vystymas, tvarkaraščio sudarymas ir procedūrų, skirtų remti projekto tikslus, vykdymas. Organizuodamas projektą, Projektų Vadovas turi apsibrėžti kompanijos struktūrą – identifikuoti darbuotojų roles ir pozicijas, nustatyti išorės įmonių paslaugų poreikį ir apsibrėžti reikalavimus personalui. Vadovavimas projektui remiasi projekto plano įgyvendinimu, siekiant užsibrėžtų tikslų. Šiame etape Projekto Vadovo sėkmę lemia plano stiprumas ir asmeniniai įgūdžiai, tokie kaip gebėjimas aiškiai komunikuoti, motyvuoti komandos narius bei spręsti konfliktus. Projektui įgavus pagreitį, Projektų Vadovas negali prarasti kontrolės. Galutinė projekto sėkmė priklauso nuo projekto matavimo (pažangos tikrinimo), įvertinimo (nukrypimo nuo plano priežasčių nustatymo) ir taisymo (nukrypimo padarinių sprendimo).

Kada Projektų Vadovas, o kada Scrum Meistras?

Pereidamos prie Scrum metodikos taikymo, įmonės dažnai susiduria su problema, kuomet yra painiojama Projekto Vadovo ir Scrum Meistro rolė. Projektų vadovų funkcijos apibrėžtos labai plačiai. Jie patys valdo darbo procesus, skirstosi užduotis, sprendžia problemas bei dėliojasi prioritetus. Projektų Vadovai laikomi komandos lyderiais, sprendimų priėmėjais ir planuotojais. Jie atsakingi už sklandžią produkto vystymo eigą, efektyvų komandos darbą ir numatytų tikslų įgyvendinimą. Paprastai tariant, Projekto Vadovas atsako už visą projekto eigą, nuo jo pradžios, iki galo.

Tuo tarpu, Scrum Meistro rolė pastebimai siauresnė, orientuota į pagalbą komandai, taikant Scrum metodiką kasdieniame darbe. Vietoj tiesioginio vadovavimo komandai, Scrum Meistras atlieka “trenerio” funkciją. Jis padeda kiekvienam komandos nariui efektyviai organizuoti savo darbą, laikantis Scrum metodikos taisyklių bei prižiūri sklandų Scrum procesų įgyvendinimą.

Taigi, pagrindinis skirtumas, skiriantis Scrum Meistrą nuo Projektų Vadovo yra tas, kad Scrum Meistras, kitaip nei Projektų Vadovas, praktiškai nevykdo produkto vystymo projekto, o tik teoriškai padeda Darbų Vykdymo Komandai efektyviai dirbti. 

Scrum Meistras – Scrum Komandos pagalbininkas, lyderis. Bendrai kalbant, Scrum Meistro pareiga yra suteikti Kūrimo Komandai žinias apie Scrum metodą bei jo taikymą, prižiūrėti kaip Komanda laikosi Scrum teorijos, praktikos ir taisyklių, o iškilus sunkumams, padėti juos išspręsti.

Pagrindinis Scrum Meistro tikslas – užtikrinti komandos darbo našumą, kuriant maksimalios vertės produktus.

Scrum meistro atsakomybės kūrimo komandai:

• Mokyti komandą savitvarkos ir organizuotumo;
• Teikti pagalbą produkto kūrimo metu ir šalinant iškilusias kliūtis;
• Prižiūrėti Scrum įvykių eigą.

Scrum Meistro rolė atlieka svarbų vaidmenį visame produkto kūrimo procese, palaikant glaudžius ryšius ne tik su Kūrimo komanda, bet ir su Produkto Šeimininku.

Scrum Meistro atsakomybės Produkto Šeimininkui:

• Ieškoti ir taikyti efektyvius metodus darbui su produktų sąrašu;
• Suvokti ir gebėti naudoti produktų planavimo metodus bei dalintis visa informacija, reikalinga vertės kūrimui.

Renkantis Scrum Meistrą, svarbu atsižvelgti į jo asmenybę ir kaip jį priima Komanda. Dažniausia problema, su kuria susiduria organizacijos yra Scrum Meistro rolės suteikimas Projektų Vadovui. Tokiais atvejais komanda jau būna pripratusi iš jo gauti konkrečias instrukcijas ir prireikia nemažai laiko, kol pavyksta pereiti prie saviorganizacijos.

Taigi, suteikti Scrum Meistro pareigas kvalifikuotam asmeniui yra sveikintina, tačiau ne ką mažiau svarbu ir atsižvelgti į jo asmenines savybes bei santykį su komanda. Geriausi Scrum Meistrai paprastai būna tie, kurie mėgaujasi padėdami ir geba džiaugtis kitų sėkme lyg sava.

Iš pirmo žvilgsnio gali pasirodyti, kad Scrum Meistras vadovauja Komandai, tačiau, iš tiesų, komanda pati organizuoja savo darbą bei skirstosi užduotis. Scrum meistras tik pakreipia ją tinkama linkme ir padeda teisingai pasiskirstyti darbo krūvį. Taigi, Scrum Meistras nėra nei koordinatorius, nei vadovas, todėl jis turi gebėti įsiklausyti ir priimti Komandos bei Scrum Šeimininko tempą, norus ar nuomonę, tuo pat metu, prižiūrėdamas ir užtikrindamas darbo efektyvumą.

Komandoms dažnai tenka susidurti su išoriniais trikdžiais, tokiais kaip įvairios užklausos ir prašymai programuotojams iš kaimyninių skyrių, kurie trukdo darbą ir mažina veiklos našumą. Tokiu atveju, Scrum Meistro pareiga yra sureguliuoti šiuos nesklandumus, nukreipiant adresantus tinkama linkme ir padedant jiems gauti reikiamą informaciją, tuo pat metu, maksimaliai išvengiant Komandos narių sutrukdymo.

Scrum Meistras turi išmokyti organizacijos narius Scrum metodikos ir paaiškinti kokią naudą teikia jos paisymas. Tai garantuos organizacijos savivokos apie Scrum svarbą formavimąsi ir savanorišką taisyklių laikymąsi.

Taigi, Scrum Meistras yra tarsi sporto treneris, kuris skatina siekti geriausių rezultatų ir padeda rasti tinkamiausius būdus tai padaryti. Kaip bebūtų, procesas, siekiant išsikeltų tikslų, nėra Scrum Meistro atsakomybė. Jo misija ne nurodyti kaip atlikti darbą, o padėti nepasiklysti taikant Scrum metodą savo darbe.

Paprastai tariant, Scrum yra produktų kūrimo sistema, kurioje taikomi įvairūs procesai ir technikos. Tai vienas iš populiariausių Agile projektų valdymo metodų, aprašančių konkrečias roles ir taisykles, kuriomis vadovaujantis vykdomi projektai.

Scrum remiasi empirizmo teorija, teigiančia, kad priimant sprendimus, yra pasikliaujama žiniomis, o žinios ateina iš patirties.

Scrum procesai valdomi skaidriai – visi veiklos aspektai yra atviri ir matomi, tikrinamas darbo progresas, jei reikia, atliekamos korekcijos.

Scrum komandą sudaro:

• Profesionalai, atliekantys darbą;
• Produkto šeimininkas (product owner), atsakingas už maksimalią komandos atliekamo darbo vertę;
• Scrum meistras (Scrum master) – komandos pagalbininkas, prižiūrintis Scrum teorijos, praktikos ir taisyklių laikymąsi.

Rekomenduojamas komandos dydis – iki dešimties žmonių, kad būtų užtikrintas tvarus ir patogus bendradarbiavimas.

Siekiant reguliarumo ir mažinant neapibrėžtų veiksmų vyravimą, Scrum darbas organizuojamas ribotos trukmės įvykiais – sprintais, padedančiais efektyviau atlikti numatytus darbus.

Sprinto eiga:

• Naujo sprinto pradžioje, produkto šeimininkas paskiria užduotis, iš kurių kolektyvas pasirenka svarbiausias ir nusistato preliminarią jų trukmę. Laiko planavimas leidžia įvertinti savo galimybes ir efektyviai atlikti darbus. Tam, kad kolektyvas suprastų procesą ir jo laikytųsi, Scrum meistras prižiūri darbo eigą.
• Prasidėjus sprintui, vykdomi kasdieniai susirinkimai, kuriuose komandos nariai pristato atliktus darbus bei iškilusias problemas. Tai padeda palengvinti ir paspartinti jų sprendimą, neišklystant iš nusistatytų laiko rėmų.
• Sprintui einant į pabaigą, atlikti darbai pristatomi klientui. Pristatymas vyksta apžvalgos susirinkimo metu, dalyvaujant keliems komandos nariams bei produkto savininkui. Šio susirinkimo tikslas – ne tik parodyti progresą, bet ir gauti kliento atsiliepimus bei įvertinimus, į kuriuos atsižvelgdama komanda gali koreguoti savo darbų planą, prisitaikyti prie pakitusių rinkos poreikių.
• Kiekvienas sprintas uždaromas apžvalgos susirinkimo metu, skirtu aptarti nuveiktą komandos darbą ir galimus patobulinimus ateityje.

Scrum projektai tęsiasi pasikartojančių sprintų principu tol, kol yra patenkinami visi kliento poreikiai (user stories) arba, esant ribotam laikui, tol, kol sukuriamas pakankamą vertę klientui teikiantis produktas.

Svarbiausi Scrum aspektai, suteikiantys naudą vartotojui:

• Lankstumas – projekto skaidymas į dalinius projektus (sprintus), leidžiantis reaguoti į rinkos pasikeitimus bei naujas idėjas;
• Kolektyvinės dvasios palaikymas – dirbant nedidelėje grupėje lengviau diskutuoti ir spręsti problemas;
• Skaidrumas – visi projekto dalyviai turi prieigą prie darbų sąrašų, diagramų bei vertinimų.
• Reguliarumas – pastoviai gaunami ir tikrinami tarpiniai rezultatai.