Efektívna retrospektíva

agile.retrospectives

V rámci agilných metód sa často odporúča pracovať v iteráciách. Tie totiž okrem iného umožňujú vykonávať v pravidelných intervaloch reflexiu voči stavu projektu. Jednou z takýchto reflexií je retrospektíva (inou je napríklad demo produktu). Kvalitnej retrospektíve môže stáť v ceste niekoľko prekážok. Napríklad vnútorné rozpory v tíme, nízka angažovanosť ľudí ohľadom ich práce, strach z vystupovania pred skupinou, ale aj obyčajná zábudlivosť. Práve vďaka týmto problémom je retrospektíva typ porady, ktorý si zasluhuje pozornosť a prípravu. Niekoľko veľmi dobrých tipov ako na to ponúka kniha Agile Retrospectives od autoriek Esther Derby a Diany Larsen.

Kniha začína všeobecnými radami ako viesť retrospektívu. Zaoberá sa krokmi ako vyjasnenie si cieľa, štruktúry a dĺžky retrospektívy. Ponúka postupy ako vyriešiť problémy s niektorými nežiadúcimi prejavmi ako je krik, nevhodný smiech a vystupovanie alebo aj neobvyklé ticho.

Hlavná časť knihy prestavuje katalóg rôznych aktivít, ktoré sú vhodné pre retrospektívu. Sú rozdelené do piatich oblastí totožných s piatimi fázami retrospektívy:

1.       Set the Stage – aktivity na zahriatie a prebranie ľudí

2.       Gather Data – získanie údajov ohľadom fungovania tímu a jeho problémov

3.       Generate Insights – premena údajov na informácie; snaha nájsť podstatu problému

4.       Decide what to do – rozhodnutie o ďalších krokoch v rámci riešenia problémov

5.       Close retrospective – uzatváracia aktivita

Ku každej z týchto fáz retrospektívy ponúkajú autorky niekoľko rôznych aktivít, z ktorých je potrebné vybrať jednu pre vašu retrospektívu. Každá aktivita je popísaná v rovnakej štruktúre: účel, potrebný čas, popis, kroky, potrebná príprava a príklad na záver. Dokopy sa v tomto katalógu nachádza 30 rôznych aktivít, čo ja osobne považujem za dostatočnú zásobu na niekoľko mesiacov alebo rokov (podľa toho ako často retrospektívu vykonávate).

Tretia, posledná, časť knihy sa venuje rôznym druhom retrospektív. Okrem klasických iteračných retrospektív je tu priestor venovaný aj release a projektovým retrospektívam alebo spoločným retrospektívam pre viaceré oddelenia firmy. Autorky sa zaoberajú rozdielmi, ktorými sa líšia tieto väčšie retrospektívy od klasickej iteračnej.

Osobne by mi nevadilo, keby bola kniha Agile Retrospectives hrubšia a niektoré témy prebrala viac do hĺbky. Na druhej strane je nutné povedať, že kníh ktoré sa priamo venujú retrospektívam, nie je veľa, a preto som autorkám vďačný za to, že do tejto oblasti priniesli aspoň aké – také svetlo. Štruktúra, ktorú vo svojej knihe navrhujú, mi pripadá rozumná a prirodzená pre riešenie problémov. Z mojich skúsenosti viem, že často dochádza k chybe, že  v reálnom živote často táto schéma nie je dotiahnutá do konca. Ak ste už niekedy zažili poradu, kde sa síce povedalo, v čom je problém, ale akosi sa zabudlo dohodnúť na tom, čo sa s tým bude robiť a kto to má na starosti, tak viete o čom hovorím (veľmi dôležitá štvrtá fáza „Decide what to do“). Ak vás stretávajú takéto alebo iné nepríjemné pocity v rámci vašich retrospektív, myslím, že je na čase prelistovať knihu Agile Retrospectives.

Ako uspieť, ak ste už raz začali

obal.succeeding.with.agile

Nie vždy sa mi stáva, že sa mi dostane do rúk kniha, ktorá by dokázala posunúť môj názor na nejakú vec naraz vo viacerých smeroch. Tentokrát som mal  opäť raz šťastie, keď som natrafil na Succeeding with Agile od Mike Cohna. Je niekoľko vecí, ktoré sa dajú o tejto knihe povedať, a jedna z nich je, že ak to myslíte s agilnými metódami vážne, tak čas strávený jej čítaním nebude určite premrhaný.

Táto kniha nie je pre ľudí, ktorí si kladú otázku: „Čo sú to agilné metódy?“, alebo „Ako vlastne vyzerá Scrum?“. Autor predpokladá, že na to už máte odpovede a vedie diskusiu viac do hĺbky adaptácie agility. Je to kniha hlavne pre ľudí, ktorí čo-to o agilných metóda vedia, niečo si aj skúsili a narazili na rôzne druhy prekážok. Jej čítaním totiž veľmi ľahko zistíte, že vaše problémy nie sú až tak unikátne ako možno vyzerajú a ich riešenie už existuje. Zaujímavé sú napríklad takzvané „časté námietky“ ľudí voči agilným metódam a Mikové odpovede na ne. Niektoré vám možno budú pripadať povedomé…

Kniha je rozdelená na päť častí, pričom v prvej autor vysvetľuje základné fakty o adaptácii Scrumu. Nečakajte ale vysvetlenie toho, čo je to sprint. Namiesto toho Mike prezentuje 5-krokový proces, ktorý je vhodný k adaptácii Scrumu a vzory šírenia agilných praktík medzi tímami. Okrem toho zavádza pre mňa veľmi príslovečný pojem „organizačná gravitácia“ – t.j. pôsobenie (sily) zvyšku organizácie voči prechode tímu na agilnú metódu. Ak prekonáte túto silu, dostanete sa na orbit (úspešná a trvalá adaptácia), ak nie, stiahne vás to späť.

Druhá časť pojednáva o jednotlivcoch. Hneď prvá kapitola vás naučí poradiť si s odporom k zmene (veľmi dobré čítanie na túto tému je aj kniha „Pocit naliehavosti“ od John P. Kottera). Ďalšie kapitoly informujú o tom, ako zaviesť nové roly, ktoré so sebou Scrum prináša (vytvorením alebo transformáciou klasických existujúcich) a ako ľudom vštiepiť technické praktiky, ktoré sú pre agilný vývoj nutné.

V tretej časti si berie na mušku fungovanie tímov. Od štruktúry tímu, cez budovanie spolupráce až po podporu samoorganizovanosti v tíme. V tejto kapitole tiež môžete nájsť informácie o tom, ako by mal vyzerať váš backlog, sprint, plánovanie a čo robiť, aby  ste do vášho produktu zapiekli dostatočné množstvo kvality.

Štvrtá časť je zameraná na väčšie organizácie. Mike prezentuje svoje znalosti ako sa vysporiadať s veľmi veľkými projektmi alebo ako zaviesť Scrum do distribuovaného prostredia. Zvláštna kapitola je venovaná spoluexistencii agilných metód s inými (klasickými) metódami v jednej organizácii. Ak ste niekedy stáli pred problémom ako riadiť projekt, ktorý je vo vnútri agilný a navonok klasický-sekvenčný, tak v tejto kapitole nájdete zopár dobrý postrehov.

Posledná časť je najkratšia, ale o to silnejšia. Mike v nej vstupuje do oblasti, o ktorej som ja osobne zatiaľ veľa literatúry nevidel, a to meranie agility. Ako veľmi ja náš tím agilný? Kde sme v porovnaní s obdobím pred rokom alebo v porovnaní s inými tímami? Ako veľa hodnoty sme dodali zákazníkovi? Ak vás trápia tieto alebo podobné otázky, tak v tejto kapitole by ste mohli nájsť zopár drahokamov medzi riadkami. Osobne ma prekvapilo, aké jednoduché praktiky sa dajú použiť, aby sme zistili, akú veľkú hodnotu dodáva tím zákazníkovi (niektoré z nich sme v našom tíme vyskúšali, a bolo naozaj zaujímavé sledovať ako zopár jednoduchých obrázkov vyjasnilo pomery).

Kniha Succeeding with Agile je určená ľudom, ktorí agilné metódy skúšajú a boria sa s rôznymi problémami, ktoré takáto adaptácia prináša. Je určená pre bojovníkov, ktorí sa rozhodli bojovať s organizačnou gravitáciou, aj pre zvedavcov, ktorí by sa už radi dozvedeli niečo viac, ako ponúka základné video o Scrume na Youtube. Je cítiť, že Mike do knihy vložil svoje dlhoročné skúsenosti a že píše o veciach, ktorým rozumie. Preto by táto kniha mala byť v knižnici každej spoločnosti, ktorá to s agilitou myslí vážne.

Agile Eastern Europe 2010

null

Aj tento rok by sme Vás radi pozvali zúčastniť sa skvelej akcie Agile Eastern Europe 2010 o Agile, Scrum, Lean atď.

Skvelý program
35 rečníkov z 18 krajín, 2 dni, 4 pódiá, 40 prezentácií
Master Classes (CSM, CSPO, Lean, Design) vedené hlavnými rečníkmi!

Web: http://agileee.org
Kedy: 8-9 októbra 2010
Kde: Kyjev, Ukrajina

Zaregistrovaním sa získate vstupenky so zľavou,výšku ktorej momentálne dohadujeme s organizátormi Agile Eastern Europe.

Agile Eastern Europe 2010 is near!

Pridajte sa k skupine Agile@Slovakia a zúčastnite sa skvelej konferencie  Agile Eastern Europe usporiadanej tímom aj u nás známeho Alexeja Krivitského. 

Kyjev, Ukrajina, Október 2010.

Naša skupina získala zľavu na vstupnom. Ak máte záujem kontaktujte founders at agile.sk.

Mimochodom, vo videu sú aj Slováci, ktorí minulý rok cestovali s nami.

Agileee is calling you! from Agile Eastern Europe on Vimeo.

ScrumMaster, alebo prečo to nie je také jednoduché

Na Agileee 2009 som mal tú možnosť sa účastniť diskusie niekoľkých prednášajúcich tejto konferencie. Okrem iných tém sa v jednom momente diskusia viedla o tom, kto to má byť ScrumMaster. Zatiaľ čo niektorí tvrdili, že je to človek, ktorý musí byť zručný pri práci s ľudmi a organizovaní, iní tvrdili, že to môže robiť aj ich 5-ročný syn. Že je to pozícia, ktorá nevyžaduje žiadne špeciálne zručnosti, pretože človek vykonáva len jednoduché veci ako kreslenie grafu alebo varenie kávy pre tím. Verím, že rozlúsknuť tento problém nie je jednoduché, ale aj tak sa pokúsim prispieť k objasneniu.

Máme tu teda dva typy ScrumMastera. Jedného ako silného vodcu, ktorý zvláda prácu s ľuďmi, rozumie agilným metódam a má silné zručnosti v oblasti organizovania práce. Na druhej strane je to niekto, kto vykonáva rutinné práce potrebné na to, aby tím mohol nerušene pracovať. Tieto dva typy predstavujú opačné strany spektra, pričom typy ScrumMasterov v jednotlivých tímoch sa môžu pohybovať v ňom.

Je nutné povedať, že na tím sú kladené požiadavky. Tieto požiadavky môžu byť vnútorné, čo napríklad môže znamenať, že tím musí byť schopný uskutočniť poradu, vyriešiť konflikty alebo navrhnúť riešenie nejakého problému, a tiež vonkajšie, ako napríklad, že musí odovzdávať prehľady o svojej práci alebo musí byť schopný zodpovedať otázky ohľadom plánovania.

Predstavme si teraz na chvíľu absolútne ideálne samoorganizovaný tím. Je to skupina ľudí, ktorá (ako skupina) dokáže tieto požiadavky splniť. Ak treba aby sa uskutočnila porada, tak sa niekto postaví, poradu zvolá a odmoderuje ju. Ak treba vyriešiť problém, tak sa zíde niekoľko ľudí, dajú hlavy dokopy a nájdu najlepšie riešenie. Niekto kreslí graf a niekto pomáha s riešením konfliktov. Takto by mohol vyzerať ideálny svet.

V reálnom svete ale tím nie je schopný splniť všetky tieto požiadavky. Nedokáže napríklad sám zvolať poradu. Dôvody môžu byť rôzne ale faktom je, že v schopnostiach tímu plniť požiadavky môžu byť rôzne medzery. A práve tieto medzery musí zaplniť ScrumMaster. Som presvedčený, že práve preto táto pozícia vznikla. Aby bola schopná zastúpiť tím v akciách, ktorých sám nie je schopný. Je dôležité povedať, že dobrý ScrumMaster by mal vykonávať len veci, ktoré tím nezvláda spraviť sám, čo je jeden z rozdielov medzi vedúcim tímu a ScrumMastrom. K tomu sa ale dostaneme neskôr.

schopnosti.vs.poziadavky

Ak sa teda vrátim k dileme, ktorú som popísal na začiatku, tak jednoznačná odpoveď je, že ScrumMaster by mal mať také schopnosti, ako vyžaduje situácia tímu, teda rozdiel medzi tým, čo sa od tímu požaduje a čo je schopný plniť. Ak je to tím ľudí, ktorý agilné metódy nikdy nepoužívali, tak ScrumMaster musí byť veľmi skúsený a zručný. Naopak v tíme, ktorý už agilne funguje dlhšiu dobu a kde je vysoká samoorganizovanosť, ScrumMaster môže mať len veľmi málo úloh a zodpovedností. Preto neexistuje finálny zoznam povinností ScrumMastera. Tento zoznam by musel byť zostavený pre každý tím zvlášť.

Okrem tohto dôležitého faktu, je tu ešte jedna vec, a to, že ScrumMaster nie je iné meno pre vedúceho tímu. Medzi týmito dvoma rolami je veľký rozdiel. V prvom rade je to pozícia voči tímu. Vedúci tímu je v hierarchii nad tímom. Je to niekto, na koho je možné eskalovať problémy a kto je naopak schopný delegovať prácu. Zároveň väčšinou preberá zodpovednosť za výsledok tímu.

veduci.timu

Úlohou ScrumMastera je ale tímu pomáhať. Preto je jeho pozícia vedľa tímu alebo dokonca pod ním. V žiadnom prípade by nemal preberať zodpovednosť a rozdeľovať prácu by mal len v prípade, ak si ju tím nie je schopný rozdeliť sám (čo na určitom stupni samoorganizovanosti musí byť schopný). Ale čo je najdôležitejšie, zatiaľ čo vedúci tímu má vymedzené povinnosti a práva a tie sa prirodzene nemenia, ScrumMaster by sa mal prispôsobovať tímu (to znamená, nevykonávať činnosti, ktoré je tím schopný vykonať sám) a mal by tím viesť k tomu, aby bol schopný čo najviac plniť požiadavky, ktoré sú na neho kladené.

scrummaster

Práva a povinnosti ScrumMastera sa môžu teda časom meniť a pri správnom smerovaní by sa mali zmenšovať a oslabovať. Táto zmena filozofie roly môže byť najväčšia výzva pri prechode na agilné metódy zo starého systému riadenia, pretože ľudia sa len neradi vzdávajú moci kontrolovať a ovládať.

Na záver už len jedna rada ako preniesť na tím viac kompetencií ScrumMastera: nechať jeho pozíciu rotovať. Za určitého dozoru a prispenia zvonku je možné, aby ScrumMastrom bol každý sprint niekto iný. Toto je veľmi dobrý spôsob, ako dať ľudom pocítiť, že prácu, ktorú doteraz vykonával niekto konkrétny dokáže vykonávať každý. Že na nakreslenie grafu alebo zvolanie porady nie sú potrebné nijaké zvláštne danosti. Časom sa môže stať, že pozícia ScrumMastra natoľko oslabí, že už bude skoro jedno, kto to je. A to bude príznak, že tím ide správnym smerom.

Scrum Norris – SCRUM v podaní legendy :)

Nedávno som narazil na úžasnú zbierku SCRUMáckých Chuck Norrisoviek.. celkom slušný útok na bránicu 🙂
Mať tak v tíme Chucka..

Enjoy 😉

  • Chuck Norris is ScrumMaster and ProductOwner – simultaneously.
  • Chuck Norris can do 6-month sprints.
  • Chuck Norris wears Timeboxershorts.
  • Chuck Norris does not move story cards, he moves the taskboard.
  • Chuck Norris does not estimate, he knows.
  • Chuck Norris pairs alone.
  • Chuck Norris starts project with a Roundhouse-Kickoff.
  • Chuck Norris is allowed to appear late at the stand-up.
  • Chuck Norris sits on the stand-up meeting.
  • Chuck Norris has implemented everything at the planning meeting.
  • Chuck Norris does not estimate user stories, user stories estimate him. (This doesn’t translate well.)
  • Chuck Norris writes the code first, then the test.
  • Chuck Norris is not afraid of bugs, bugs are afraid of him.
  • Chuck Norris does not do Kanban. He does not know limits.
  • Chuck Norris does not pull, he pushes.
  • When Chuck Norris says “done”, then it’s “done”.
  • Chuck Norris does not deploy, he develops on the production environment.
  • Just Chuck Norris knows, that a real burn-down requires napalm.
  • Chuck Norris has no burn-down chart. Around him everything is already burnt down.
  • Chuck Norris answers just two questions on the stand-up meeting. Chuck Norris does not know obstacles.
  • Chuck Norris does not prioritize the backlog.
  • Chuck Norris takes two baby-steps at once.
  • Chuck Norris does not use test-driven development. Chuck Norris always drives.
  • Chuck Norris is the prioritized backlog.
  • Chuck Norris is ScrumMaster without being certified.
  • Chuck Norris does not need acceptance tests. Either Chuck Norris accepts or not.
  • Chuck Norris does not need Iteration Reviews or Reflection Workshops. There is no improvement for Chuck Norris’ process.
  • Chuck Norris’ unit tests pass, before he has written the code.
  • Tests doesn’t fail in front of Chuck Norris
  • Chuck Norris writes the code first, never the test(He doesn’t need to test at all).
  • Chuck Norris always wins at Planning Poker.
  • Chuck Norris can keep silent to small-size efforts.
  • Chuck Norris does not need a reference task.
  • Chuck Norris doesn’t do iterative development, it’s right first time, forever.
  • Chuck Norris does not plan to release. Chuck Norris knows what to do.
  • Chuck Norris has a velocity of 50 000 points.
  • Chuck Norris ends the Product Backlog in each iteration.
  • Chuck Norris sidekicks chickens while eating fresh bacon at the stand-up
  • Chuck Norris developed his own crib in one iteration, right after birth
  • When Chuck Norris walks by, tests don’t run, they die in fear
  • Chuck Norris’ velocity is infinite, he can run around the world and punch himself in the back of the head.
  • Chuck doesn’t meet customer requirements, they meet his!

Kanban – ďalší nástroj agilných projektov

Kanban je ďalší nástroj v skupine agilných metód, kde sa nachádza aj Scrum. Je kompatibilný s agilným manifestom a nepopiera agilné princípy. Oproti Scrumu je však menej reštriktívny a je založený na veľmi jednoduchej myšlienke:

Nedokončená práca (Work-in-progress alebo WIP) by mala mať svoje obmedzenie a nová práca sa môže začať len vtedy, keď sa iná práca dokončí (alebo posunie do iného stavu).

Kanban (v japončine “signalizačná tabuľka”) predpokladá, že vznikne vizuálny signál o tom, že sa môže rozpracovať novú úloha, pretože aktuálne množstvo rozrobenej práce ešte nedosiahlo svoj limit.

Kanban schéma

(c) Henrik Kniberg & Mattias Skarin: Kanban and Scrum – Making the most of both (InfoQ 2010)

Znie to zaujímavo ? Na prvý pohľad možno nie, možno je to malá, nenápadná myšlienka, ale môže zmeniť všetko v doterajšom procese! Kanban totižto nie je proces ani metodika, je to spôsob ako zaviesť zmenové riadenie (change management) do existujúceho životného cyklu softvérového vývoja. Bol vytvorený ako časť Lean iniciatívy s cieľom transformovať firemnú kultúru na nepretržité zlepšovanie (Continuous Improvement).

Princíp Kanbanu – začať s tým, čo robíme teraz. Pochopíme proces zobrazením dôležitých tokov a nastavíme limity na každý stav tohto procesu. Potom začneme pracovať s tokom úloh v systéme tým, že ich vyberáme len vtedy, keď je vygenerovaný Kanban signál. Toto spôsobí, že sa v niektorých stavoch začnú úlohy blokovať a upchávať systém. To je to, čo sme chceli – tím v čo najkratšom čase odstráni problém a obnoví tak tok úloh. Pochopením príčin, upravovaním limitov WIP prípadne zmenou stavov procesov sa celý tok stáva priechodným.

Kanban takto vďaka transparencii zviditeľňuje úzke hrdlá, fronty, nestálosti a zbytočnosti – toto všetko má vplyv na výkonnosť z pohľadu množstva užitočnej práce a doby cyklu (začaté – odovzdané). Prehľadnosť sa dá ľahko zabezpečiť tým, že sa použije tabuľa/stena s lístočkami. Lístoček (Post-it) je ten vizuálny signál, ktorý som spomenul na začiatku.

Pravidlá sú iba dve:

  1. vizualizuj svoj pracovný tok
  2. limituj svoj WIP

Ešte spomeniem stručné podobnosti Kanbanu so Scrumom:

  • sú Lean a Agile
  • používajú plánovanie vyberaním úloh
  • obmedzujú WIP
  • používajú prehľadnosť na riadenie procesu zlepšovania
  • sústreďujú sa na vytvorenie potencionálne dodateľného produktu rýcho a často
  • stavajú na samoriadenie sa tímu
  • požadujú rozdelenie práce na menšie časti
  • release plán je priebežne upravovaný na základe empirických dát (velocity/lead time)

Odlišnosti Kanbanu od Scrumu:

  • časovo obmedzené iterácie (Sprint) sú voliteľné, nie povinné
  • záväzok tímu je voliteľný, nie povinný
  • používa Lead Time ako metriku na plánovanie a vylepšenie procesu, nie Velocity
  • všestranný tím je voliteľný, špecializované tímy/jednotlivci su povolené
  • roly nie sú preddefinované
  • veľkosť úloh môže byť ľubovolný
  • burndown grafy nie sú povinné
  • WIP obmedzuje priamo, Scrum nepriamo
  • odhady sú voliteľné
  • nové úlohy sa môžu pridávať do zoznamu hocikedy, ak to dovoľuje WIP limit
  • Kanban tabuľa nie je špecifická pre jeden tím, môže ju zdieľať viacero tímov alebo jednotlivcov
  • Kanban tabuľa pretrváva a neruší sa po každej iterácii
  • prioritizácia nie je povinná ale voliteľná

Myslím, že stojí za to sa nad Kanbanom zamyslieť a zvážiť jeho výhody a prípadné dôsledky. Má menej obmedzení ako Scrum, takže jeho akceptácia v tíme môže byť jednoduchšia, navyše kto má skúsenosti so Scrumom a narazil na niektoré jeho obmedzenia, je možno toto ten správny impulz, že je čas sa posunúť zase o kúsok ďalej.

Soft – Skills v SCRUM (Inšpirácie ScrumImpulz 2010)

Autor: Tibor Šipocz, Mária Dobešová

Vo svojej práci sa stretávame s niekoľkými princípmi ako by manažéri mali viesť svojich ľudí v práci, v projektoch. Tréneri mäkkých manažérskych zručností zdôrazňujú a na tréningoch nacvičujú manažérov, aby používali taký prístup k ľuďom, ktorý je motivujúci zvnútra, rozvíja pracovníka a napĺňa potreby jeho i potreby klientov. Veľká väčšina týchto princípov je inherentne obsiahnutá v agilných metódach riadenia projektu, v SCRUM osobitne.

 Takže sme sa mi „kauči“ zhodli, že silné motivujúce prvky sú:

  • spoluúčasť na stanovovaní cieľov a rozhodovaní a riešení problémov (daily meetings, výber taskov,..)
  • spoločne dohodnuté pravidlá a kritéria posudzovania (odmeny, benefity resp. tresty za výkon)
  • spolupráca členov tímu od samého začiatku projektu (krátke šprinty to vynútia na rozdiel od tradičných postupov)
  • preberanie zodpovednosti za svoj podiel práce i za celý tím (šprint musí byť ukončený, merateľný výsledok, user story)
  • časté odovzdávanie medzivýsledkov – čiastočné úspechy povzbudzujú (odovzdaný funkčný blok, release)
  • okamžitá spätná väzba a podpora od ostatných členov tímu i od klienta (daily meetings)
  • intenzívna komunikácia a tímová spolupráca – tímový duch (spoločné sedenie, časté i neformálne stretnutia…)

 Prvky, ktoré podporujú osobný rozvoj každého člena tímu a rozvoj tímu ako celku:

  • zdieľanie know-how počas celého projektu – napr. práca v pároch, tímové stretnutia, spoločná databáza metód, techník
  • informovanosť o celkovom dianí na projekte – problémy a ich riešenia na každodennej báze
  • cielené vzdelávanie a koučovanie ostatnými členmi tímu – semináre, telekonferencie, zaúčanie nových členov tímu
  • učenie sa z chýb po každom cykle – chyby sú povolené, je priestor na to, aby sa napravili
  • možnosť individuálneho výberu takých úloh, ktoré sú „výzva“ – nové veci zo zoznamu taskov
  • zohľadnenie individuálnych preferencií – podpora zvoleného spôsobu učenia, priestor pre kreativitu a zmeny
  • zvyšovanie sebadisciplíny jednotlivcov – prácu je potrebné ukončovať v krátkych intervaloch (na ilustráciu tohto vieme nakresliť pekný obrázok)
  • príležitosť na rozvoj zručností vedenia ľudí, projektu – napr. striedanie v roli scrummastera
  • tím sa rozvíja spoločne, rastie úroveň spolupráce – napr. prostredníctvom retrospektívnych stretnutí

Spolupráca s klientom v agilných metódach umožňuje lepšie napĺňať potreby klienta:

  • rola product ownera zaručuje priebežné sledovanie priorít – potreby klienta sú jasne komunikované a rozsah práce je predmetom vyjednávania
  • jednotlivci i tím má istotu, že nerobí zbytočné veci a smeruje k cieľu, ktorý naplní ich potreby

Tieto prednosti agilných metód (SCRUMu) nie sú vždy využité v plnej šírke. Počas konferencie ScrumImpulz 2010 i následnom Bootcampe sme videli ako sú tieto nesporné výhody uvedomene využívané, avšak i nedocenené resp. nevhodne interpretované alebo nepochopené. Je to  nevyužitá príležitosť pracovať v projektoch úspešnejšie. Je na to potrebná zručnosť pri vedení ľudí, ktorá sa dá nadobudnúť iba praxou a cieleným tréningom.  V tom môžeme projektovým tímom pomôcť my – tréneri, kauči.

Niektoré prvky, ktoré sú motivačné v SCRUM bežne učíme používať napr. v tréningovom module Motivácia a hodnotenie, ktorý sa zaoberá motivovaní ľudí všeobecne. Patria tam teórie motivácie – expectancy theory i teória stanovovania cieľov, dôsledky pravidelnej spätnej väzby a hodnotiacich rozhovorov. Budovanie tímu a tímová práca sa zase detailne venuje tomu ako zostaviť projektový tím a cielene ho viesť k vysokej výkonnosti. Leadership čiže Vedenie ľudí  vo všeobecnosti, či Projektový manažment –  v zmysle – vedenie ľudí v projektoch cielene rozvíja zručnosti koordinátora. ScrumMaster  by určite mal rozvíjať svoje facilitačné zručnosti v tréningu nazvanom Vedenie porád alebo Moderovanie, či Kreatívne techniky riešenia problémov.  

Celkove sa dá stimulovať všestranný rozvoj zainteresovaných strán v SCRUM projekte. Najviac by mohol pomôcť výcvik v používaní koučovacích techník v tréningu  Koučovanie.

Pri jednaní s Product Ownerom zase môžu pomôcť tréningy z názvom Obchodné vyjednávanie či Ovplyvňovanie a argumentácia. Vzťah tímu a najmä ScrumMastera ku klientovi je v podstate konzultačný – pomohli by Konzultačné zručnosti.

 Z nášho pohľadu najdôležitejšie zložky, ktoré treba podporovať sú:

  • Základné manažérske zručnosti pre všetkých ( rozhodovanie, plánovanie…)
  • Partnerstvo od začiatku projektu (vízia, misia, hodnoty, ciele, stotožnenie)
  • Budovanie tímu a špeciálne zručnosti koordinátora a vyzývateľa pre scrum mastra
  • Dávať a prijímať spätnú väzbu priebežne i po skončení projektu
  • Všímať si a oslavovať úspech (hodnotenie, oceňovanie, motivácia)
  • Práca s chybami (motivácia, risk taking, rozdiely medzi ľuďmi)
  • Metódy riešenia problémov, skupinové kreatívne techniky
  • Learning lessons (rozprávať o problémoch, ktoré sme vyriešili)
  • Zručnosti kouča (každý koučuje každého, skupinový koučing)
  • Zručnosti Project ownera (vyjadrovanie sa, priority, motivácia, počúvanie,…).

 Možno by stálo za to spoločne pripraviť program na rozvoj soft skills v SCRUMe. V tomto ohľade bol pre nás ScrumImpulz 2010 rozhodne inšpirujúci.