ScrumMaster je jeden z najdôležitejšách prvkov Scrumu, ak chceme byť úspešní.

Prvý kľúčový bod a zároveň najčastejšie nepochopenie tejto role – ScrumMaster nie je manažér Tímu, neriadi ho. Vyplýva to už z názvu tejto role – “ten kto ovláda Scrum”. ScrumMaster teda Tím podporuje, slúži mu, ochraňuje ho pred vonkajšími vplyvmi a usmerňuje ho, aby bol Scrum pochopený a správne aplikovaný. Prechod na agilné princípy nie je jednoduchý, od samého začiatku zviditeľňuje skryté prekážky v organizácii – práve počas týchto náročných zmien je potrebná úloha ScrumMastera.

Rola ScrumMastera teda zahŕňa následovné zodpovednosti:

• ochraňuje Tím pred vonkajšími vplyvmi, ktoré by mohli jeho prácu narúšať
• odstraňuje každodenné prekážky, ktoré by mohli znížiť efektivitu práce Tímu
• koučuje Tím, Product Ownera a celkovo organizáciu, aby dodržiavali pravidlá Scrumu a integrovali agilné praktiky, sledujúc pritom cieľ – úspešné a efektívne nasadenie Scrumu
• koučuje Tím, aby správne nasadil a používal vhodné XP praktiky
• koučuje Product Ownera, aby pracoval efektívne s Product Backlogom, s požiadavkami na produkt, aby maximalizoval návratnosť investícií
• podporuje dosiahnutie zhody medzi očakávaniami Product Ownera a prísľubom Tímu – mediátor v ich komunikácii
• organizuje a pomáha viesť porady predpísané Scrumom

Zo začiatku sa na túto rolu odporúča priradiť osobu na plný úväzok. Členovia Tímu sa ešte len zoznamujú so Scrumom v ich každodennom živote, manažment hľadá možnosti, ako zasahovať do iterácií,  vývojové prostredie a testovacie nástroje nie sú pripravené na agilné procesy… toto všetko predpovedá, že ScrumMaster bude mať plné ruky práce.  Neskôr, ako sa Scrum a agilné myšlienky stávajú samozrejmosťou, nástroje sú automatizované a XP praktiky sa plnohodnotne využívajú, význam dedikovaného ScrumMastera klesá a jeho kapacita sa môže postupne presúvať na členov Tímu, napríklad rotovaním tejto role.

Koho do role ScrumMastera dosadiť ? V prvom rade takú osobu, ktorá už má skúsenosti s agilnými princípmi a vývojom, je do Scrumu zaškolená a verí v agilné princípy. Tieto predpoklady netreba podceniť, medzi agilnými projektami a chaosom je relatívne tenká línia, takže neskúsený ScrumMaster môže narobiť viac škody ako úžitku. Je to teda ten, kto vie o Scrume najviac a je ochotný a schopný tieto vedomosti šíriť ďalej a presadzovať ich nielen v Tíme ale aj v celej organizácii. Je tiež užitočné, ak má ScrumMaster zároveň praktické znalosti z projektového manažmentu, dizajnu, kódovania a testovania, takže sa ľahko stotožní so vznikajúcimi problémami a vie ich promptne riešiť. Ak však bol ScrumMaster pred prechodom na Scrum vedúcim tímu / projektovým manažérom, jeho zmena myslenia môže byť veľmi ťažká – musí v sebe potlačiť tendenciu prikazovať členom čo a ako robiť, plánovať, rozhodovať za nich o riešeniach alebo prideľovať konkrétne úlohy. Samoriadenie Tímu ako nástroj na zvýšenie efektivity potom nezafunguje.

Ako už bolo spomenuté, časom sa môže rola ScrumMastera obsadiť členom Tímu. Neplatí to však v prípade kombinácie ScrumMaster-Product Owner. Tieto roly sú často vo vzájomnom rozpore a človek na dvoch takýchto stoličkách má ťažké sa rozhodnúť, koho rolu má v ktorej situácii hrať. Napríklad Product Owner je pod tlakom priorít v požiadavkách a ak v sebe potlačí zodpovednosť ScrumMastera, tak môže urobiť takú zasadnú chybu ako meniť Tímu úlohy počas Sprintu. Bez druhej osoby mu chýba jasný protiklad, ktorý by ho upozorňoval na potencionálne chyby a riziká a nasadenie Scrumu by sa minulo účinkom.

Mnoho z ľudí sa ma počas ScrumImpulz-u pýtalo za čo je vlastne zodpovedný v Scrum-e produktový vlastník. Z Vašich odpovedí som zistil, že je pokladaný za synonymum inej riadiacej roly  (napr. produktový manažér,…). Táto rola však pokrýva podstatne viac činností.

Produktový vlastník musí mať jasnú víziu o produkte, ktorý tím má dodať. Je to práve on, kto dodáva impulzy do dennodenného rytmu vývoja. Ak chýba špecifikácia toho, čo sa má vyvíjať, tím bude stáť a časom začne byť frustrovaný.

Z hľadiska marketingu produktu by sa mal starať o:

• Obchodné ciele a stratégiu produktu – produktový vlastník definuje, kto sú cieľoví užívatelia produktu a definuje priestor, v ktorom je možné urobiť produkt úspešným
• Obchodné prípady – mal by mať prehľad o všetkých zákazníkoch a zároveň by mal s nimi udržiavať komunikáciu tak, aby ich názory a požiadavky boli zachytené, prioritizované a nakoniec aj realizované.

Produktový vlastník definuje architektúru produktu. Nie architektúru v zmysle architektúry komponent, vzťahov medzi nimi, ale:

• čo bude v produkte implementované – požiadavky. Požiadavky musí produktový vlastník prioritizovať tak, aby dosiahol čo najlepšiu predajnosť. Pravidelne udržiavané požiadavky umožňujú tímu pokračovať ďalej ak dokončil plánovanú činnosť a má momentálne čas.
• Mal by definovať ako systém bude vyzerať, kde bude používaný, kým a v akom vzťahu bude k okolitým systémom
• mal by byť zodpovedný za zdroje potrebné pre vývoj systému, či už finančné, materiálne alebo aj za tvorbu a stavbu tímov.
• sledovanie progresu projektu mu zjednoduší plánovanie releasov, komunikáciu so zákazníkmi a umožní mu pripraviť zákazníkov na novú verziu dopredu – či už organizačne alebo udržaním “napätia”. Sledovanie priebehu projektu zároveň umožňuje priebežne meniť priority podľa možností tímov, potrieb zákazníkov a aktuálneho stavu produktu.

Zároveň ale má byť v kontakte s vývojovým tímom a má byť k dispozícii tak, by tím mal dostatok informácií pre implementáciu. Produtkový vlastník musí byť k dispozícii počas plánovania produktu (product planning meeting, sprint planning meeting) a počas predvádzania produktu, kedy by mal jednoznačne akceptovať alebo neakceptovať implementáciu dokončenú počas iterácie.

Túto otázku sa často pýtam najmä ľudí pracujúcich v manažmente spoločností. A odpoveď na Slovensku je vo veľkej väčšine nie. Je zvykom používať pre riadenie projektov osvedčené metódy. Len málokedy sú však osvedčené aj výsledkami projektu.

Na druhej strane stoja agilné metódy, ktoré už dnes nie sú novinkou.  Jednou z agilných techník je Scrum.

Scrum je agilným frameworkom, ale nie metodikou. Teda sadou postupov, ktoré sa majú prispôsobiť konkrétnej spoločnosti. Je založený na úzkej kooperácii medzi zákazníkom a  vývojovým tímom.

Ak by som mal Scrum popísať jednou vetou, znela by asi takto:

Hodnota je vytvorená počas iterácie celým tímom podľa priority a vôle zákazníka

Hodnota

Hodnotu prináša výsledok, ktorý  je skutočne dokončený a  otestovaný, ktorý sa dá okamžite používať.  Nie diagram, nie dokument. Keďže vývoj trvá kratší interval ako je bežné v iných postupoch, takýto skorý výsledok prináša výhodu rýchleho získania spätnej väzby od klienta.  Následne sa implementácia môže ľahko prispôsobiť požadovaným zmenám ešte v čase, kedy sa produkt tvorí.

Iterácia

Iterácia určuje obdobie, v ktorom má tím priestor pre svoju prácu. Iterácia v Scrume trvá zvyčajne 2-4 týždne.

Každá začína plánovaním práce, ktorá má byť v rámci iterácie urobená, a končí sa  prezentáciou výsledkov.  V úvode iterácie by mal zákazník odprezentovať tímu čo potrebuje, ako si predstavuje výsledok a poskytnúť potrebné vysvetlenia. Na konci tím musí urobiť prezentáciu výsledku. 

Počas nej by sa zadanie nemalo meniť, čím sa vytvorí priestor pre tím a pre samotnú realizáciu bez vyrušenia. Zároveň tím je oboznámený s progresom implementácie a v prípade problémov okamžite reaguje. Pre iteráciu sa v Scrume používa pojem sprint.

Celý tím

Celý tím v Scrume znamená zákazníka, analytika, dizajnéra, programátora, testera a ďalších. Zameranie vývoja na vlastnosti poskytuje priestor pre spoluprácu všetkých tzpických rolí.  Zatiaľčo jedna vlastnosť môže byť analyzovaná, ďalšia sa už môže testovať. Takéto kolektívne spracovanie vlastností vedie k všeobecnej znalosti implementácie produktu v rovnakom čase.

Tím je v tom istom čase obohatený intenzívnou komunikáciou a spoluprácou, ktorá je jednoznačným prínosom z dlhodobého hľadiska.

Priorita a vôľa zákazníka

Zákazník je v Scrume kľúčový element riadiaci postupnosť vývoja vlastností a akceptujúci výsledky. Rozhoduje aj o tom, či sa bude vo vývoji pokračovať nasledujúcou iteráciou.

Takéto zahrnutie zákazníka do vývoja je inovatívnym prvkom agilných postupov. V praci však často zistíme, že zákazník ani nechce byť integrovaný do vývoja. Pozor, v tomto prípade sa nepriamo vytvára možnosť, že tím nebude realizovať to čo potrebuje. Pre rozpoznanie potrieb je preto dobré ustanoviť rolu produktový vlastník, ktorý zákazníka a užívateľov zastúpi. Bude zodpovedný za stanovenie, popis a priority jednotlivých vlastností.