Scrum je o práci v tíme. A bez toho, aby sa tím stretával (online či offline), spoločne sa rozhodoval, vyhodnocoval a aj chválil, to jednoducho nepôjde. Práve preto je jadrom Scrum metodológie séria opakujúcich sa eventov. Rokmi praxe sme sa naučili, ako vyťažiť z každého z nich maximum. Chce to hlavne používať vhodné nástroje a klásť tie správne otázky.

Na plánovanie môže prísť aj elektrikár

Prvým z meetingov je plánovanie šprintu. Zúčastňuje sa na ňom celý tím vrátane Scrum Mastra a trvá maximálne 8 hodín pri mesačnom šprinte. Na našich projektoch sa pobybuje niekde medzi 2 až 4 hodinami. Zámerom tohto meetingu je vypočuť si Product Ownera a spoločne zadefinovať cieľ šprintu. Následne plánovanie prechádza do rúk vývojového tímu, ktorý sa rozhodne, čo je schopný v rámci šprintu doručiť. Výsledkom eventu je plán prác na nasledujúci šprint.

Tím môže na plánovanie pozvať aj ďalších ľudí, aby mu pomohli pochopiť súvislosti potrebné pre dosiahnutie cieľov šprintu a poskytli rady. Na meeting teda môže byť prizvaný každý, kto rozumie projektu a tomu, čo má klientovi priniesť – či je to účtovník, architekt alebo elektrikár.

My pri plánovaní radi využívame tzv. User stories, na ktoré je rozdelená každá funkcionalita v rámci šprintu. Pri tvorbe user stories sa riadime pomôckou KTO/ČO/PREČO. Tá nám pomáha jasne zadefinovať kritériá, ktoré v konečnom dôsledku vedú k úspešnému dokončeniu úlohy.

User story môže vyzerať napríklad takto: Ako učiteľ (kto) chcem, aby aplikácia Edupage zobrazovala všetky novinky na webovej stránke (čo), aby boli rodičia a žiaci pravidelne informovaní (prečo).

Denný stand up pre úspešný šprint do cieľa

Výsledkom každého naplánovaného šprintu má byť splnenie stanoveného cieľa šprintu a zvýšenie hodnoty pre zákazníka. Jeho priebeh je dobré si vizualizovať prostredníctvom vhodného nástroja – v bart-e využívame Gitlab, Jiru, AzureDevOps alebo obyčajnú tabuľu. 

Každý člen tímu by mal mať svoje úlohy aktualizované na dennej báze. Je to dôležité preto, aby ktokoľvek z tímu vedel, v akom stave sú jednotlivé úlohy, a bola zachovaná transparentnosť

Napĺňanie cieľu šprintu si tím denne prechádza na standup(daily) meetingoch. Tie trvajú maximálne 15 minút. Tu vzniká aj priestor na vzájomné radenie sa v prípade problémov a návrhy na vylepšenie. 

Najpoužívanejšia praktika stand up-ov je zodpovedanie 3 otázok:

  • Čo som robil včera?
  • Čo budem robiť dnes?
  • Mám nejaké problémy, ktoré ovplyvnia cieľ šp?

Stand up by ale nemal plniť len úlohu vyslovenia statusu, ale aj zodpovedať otázku, či sa blížime k splneniu cieľa šprintu, a ak nie, ako práce potrebujeme medzi ľudí preplánovať.

Vývoj v tíme znamená aj to, že aj keď sú úlohy 1 člena tímu hotové, ale úlohy ostatných členov tímu nie, aj tento jeden člen, čo už má “odrobené”, pracuje naďalej a snaží sa pomôcť kolegom. Nezriedka sa preto na stand up-e úlohy opätovne preplánujú a rozdelia medzi ľudí na základe aktuálnej situácie. My sa riadime pravidlom, že vždy je lepšie mať odovzdané 3 z 5-tich naplánovaných vecí, ako mať všetkých 5 rozpracovaných a žiadnu dokončenú. 

Vyhodnotenie chce aj rečnícke zručnosti

Na konci šprintu, počas jeho vyhodnotenia (sprint review), sa hotové úlohy prezentujú klientovi ale aj všetkým, čo sú do projektu zainteresovaní a boli na meeting prizvaní. Ide teda o product ownera, investorov, dodávateľov, samotného klienta či dokonca vzorku zákazníkov, ktorú na stretnutie poslal klient. Vyhodnotenie trvá maximálne 4 hodiny.

Na tomto meetingu dostáva tím spätnú väzbu a zároveň sa tu hodnotí, ako bol splnený cieľ šprintu, schvaľujú sa nové funkcie, definujú ďalšie požiadavky a ukazujú hotové celky. Klient tu priamo vidí nárast hodnoty produktu. Ide o jediný meeting, kde sa môže tím stretnúť s klientom a vidieť “naživo” reakciu na produkt, ktorý vyvíja. 

Vedieť sa odprezentovať chce určitú dávku extroverzie a rečníckych zručností. Ak niektorému členovi tieto vlastnosti chýbajú, môže o prezentáciu jeho úlohy poprosiť výrečnejšieho kolegu.

Retrospektíva na vyjadrenie každého názoru

Posledným pravidelným meetingom je maximálne 3 hodinová retrospektíva. Tá môže mať veľa foriem, no jej zámer je vždy rovnaký – umožniť každému členovi tímu vyjadriť svoj názor a povedať, čo je dobré a čo by sa dalo zmeniť/vylepšiť v ďalšom šprinte. Zároveň je o sebareflexii, pochvale medzi členmi tímu a vzájomnej motivácii.

Obsah retrospektívy sa naprieč tímami nerozoberá, ide o interný meeting v rámci tímu. Dôležité je, že na retrospektíve nikto nikoho neobviňuje. Ak sa niečo nepodarilo, berie za to zodpovednosť celý tím a spoločne hľadá možnosti na zlepšenie.

Retrospektíva by sa mala vždy končiť pozitívne. Aj negatívne veci, čo sa tu rozoberajú, sú potrebné pre vyvolanie zmeny, ktorá je z dlhodobého hľadiska pozitívna.

Retrospektívy sa zúčastňuje celý tím a každý má priestor prinášať návrhy na zlepšenia. Netreba na nej ale zabúdať na introvertnejších členov, ktorým pravdepodobne nebude vyhovovať rozprávať nahlas, a preto je vhodné zvážiť využitie niektorej z online foriem retrospektívy, napríklad retrotool.io. Tu je možné vytvoriť si “nástenky”, do ktorých môžu členovia anonymne vpisovať svoje názory.

Typy násteniek, ktoré radi využívame a pravidelne striedame, aby neboli retrospektívy jednotvárne:

  • Mad | Sad | Glad
  • Liked | Learned | Lacked
  • Start | Stop | Continue
  • Fast | Furious | Fearful | Looking Forward
  • Kudos | Went well | Could be improved
  • What went well | What could be improved
  • Superpowers | Kryptonite
  • Strengths | Weaknesses | Opportunities | Threats
  • Drop | Add | Keep | Improve
  • Pride & Joy | Personal improvements | Team improvements

Všetky návrhy na zmeny, ktoré na retrospektíve padnú, sa na záver zapisujú v podobe action itemov a postupne realizujú. My ich evidujeme do Confluence nástroja, Gitlabu alebo priamo do online toolu pre retrospektívu. Najneskôr na začiatku každej ďalšej tímovej retrospektívy sa zapracovanie action itemov preveruje.

Žiaden nie je naj – alebo sú naj všetky?

Je veľmi dôležité realizovať v rámci vývoja vždy všetky 4 meetingy. Každý z nich je totiž najpodstatnejší pre iného člena tímu. Product owner potrebuje na plánovaní vysvetliť svoje požiadavky a uistiť sa, že im tím rozumie. Klient zase chce počuť výsledky a preto je preňho najrozhodujúcejšie vyhodnotenie. Vývojárský tím sa musí denne radiť a posúvať si informácie o progrese, preto je preň nevyhnutný stand up. No a scrum master považuje pravdepodobne za najdôležitejšiu retrospektívu, kde môže motivovať ľudí k čo najlepším výsledkom.

Správne nastavené a efektívne realizované meetingy tvoria pevné piliere, na ktorých je postavený každý Scrum vývoj. My si bez nich našu prácu už nevieme ani predstaviť.

Viac blogov na tému agilného vývoja nájdete v kategórii agilita