Zákazník ako spoluhráč

innovation.gamesUž sa vám niekedy stalo, že ste dali zákazníkovi niečo len preto, aby zistil, že v podstate chcel niečo iné? Teória Lean-u by na to povedala, že ste práve vyrobili odpad. Samotná chyba ale nemusela byť vo výrobnom procese, ale v tom, že zákazník nevedel vyjadriť, čo presne chce. Agilné metódy radia, že máte so zákazníkom komunikovať tak často ako sa dá. Menej rád už ale ponúkajú v tom, ako presne to máte robiť. Ako z neho dostanete informáciu, ktorú síce má, ale o tom, že ju vlastní ani sám netuší? Luke Hohmann vo svojej knihe Innovation Games odporúča zahrať si so zákazníkom hru.

Ak si pod pojmom „hra“ predstavíte Človeče nehnevaj sa, tak to ste vedľa. Dá sa povedať, že väčšinou ide skôr o psychologické praktiky zabalené do pozlátka niečoho, čo ako hra vyzerá. Napríklad Product Box. Predstavte si, že si zvoláte niekoľko zákazníkov na stretnutie. Rozdáte im biele kartónové škatule, fixy, lepidlo, nožnice, farebný papier atď. a poviete im, aby skúsili vyrobiť obal na produkt, aký by si chceli kúpiť. A keď sú hotoví, tak na dôvažok sa ešte môžu pokúsiť svoju produktovú škatuľu akoby predviesť a predať ostatným zákazníkom. Vyberú sa najlepšie návrhy, odmenia sa nejakou pozornosťou a vy si na záver odnesiete kopec škatúľ na povrchu, ktorých môžete nájsť ozajstné bohatstvo informácii o tom, čo vaši zákazníci chcú. Toto je len jedna z 12 hier, ktorú Luke prezentuje.

Okrem teoretického úvodu a praktického záveru je kniha de facto katalógom. Katalógom hier s popisom ich použitia, vlastností, dobrých rád a trikov. Niektoré hry sú také jednoduché, že sa možno až zarazíte, prečo vás to samých doteraz nenapadlo. Hry majú rôzne charakteristiky ako napríklad náročnosť fyzickej prípravy, veľkosť skupiny zákazníkov s ktorými budete hrať, doba hrania atď. Podľa týchto charakteristík a podľa účelu potom viete vybrať najvhodnejšiu hru pre danú príležitosť. Okrem toho je pri každej hre uvedená krátka teória o tom, prečo hra funguje a niekde aj reálne informácie z používania hry. Ten teoretický popis je už na hranici psychologickej literatúry, ale to už je asi dôsledok toho, že hry reprezentujú len inú formu komunikácie.

O Scrum-e som už viac krát počul, že sa robí len veľmi ťažko, ak ho s vami zákazník „nechce hrať“. Ak neuznáva pozíciu Product Ownera, ak chce presný a dlhodobý plán alebo nechce počas vývoja komunikovať. Ak však máte šťastie a zákazník Scrum hrá, možno viete vašu komunikáciu s ním posunúť opäť o úroveň vyššie. Dostať z neho informácie tak, aby najbližšie, keď mu budete prezentovať produkt, mohol povedať, že je to presne to, čo chcel. Innovation Games ponúka návody ako na to. Určite to nie je instantné riešenie, ktoré len zalejete vriacou vodu a máte okamžite výsledky. Zorganizovať a správne odmoderovať takúto akciu vyžaduje aj nejakú prax, ale to, čo získate, môže byť natoľko unikátne, že tá námaha stojí za to.

Trénovanie agilných tímov v praxi

coaching.agile.teamsObčas sa stáva, že pri zavádzaní Scrumu uviaznete v bludnom kruhu. Ten kruh je tvorený dvoma faktami: agilné metódy začnú fungovať až v momente, keď ich ľudia začnú používať a ľudia začnú nejaké metódy používať až v momente, keď vidia, že fungujú. Tento cyklus sa dá prerušiť tým, že používanie dostanú ľudia jednoducho príkazom, ale to nie je v duchu agilných metód, ktoré stavajú ľudí na prvé miesto (určite tým stratíte ich angažovanosť, čo je vzácna a ťažko nahraditeľná surovina). Našťastie má tento problém aj iné riešenie, ktoré môžete nájsť v knihe Coaching Agile Teams od Lyssa Adkinsonovej.

Kniha sa pohybuje na hranici psychológie a riadenia, pričom som mal miestami pocit, že sa viac nakláňa k psychológii. Každopádne nie je jej cieľom vysvetľovať agilné postupy. Automaticky predpokladá, že v týchto veciach už máte jasno. To, čomu sa hlavne venuje, je práca s ľuďmi a postupy ako naviesť tímy k používaniu agilných metód. Presnejšie povedané, ako by ste sa mali vy správať, aby sa vám to podarilo. V hlavnej časti Lyssa prezentuje rôzne roly, v ktorých sa môžete ocitnúť, ak sa podujmete koučovať tímy:

  • Coach-Mentor – popisuje ako zvládať rôzne techniky koučovania (tím vs. jednotlivec) ako aj spôsob koučovania v rôznych fázach sprintu (dokonca ako koučovať koučaJ );
  • Facilitator – ako učiť ľudí správne realizovať porady;
  • Teacher – ako naučiť ľudí zvládať agilné praktiky;
  • Problem Solver – riešenie problémov projektu ako aj nastavenie tímu tak, aby ich dokázal v budúcnosti riešiť sám;
  • Conflict Navigator – riešenie konfliktov v tíme. Uvádza napríklad päť stupňov konfliktu: Problém, Nesúhlas, Spor, Križiacka výprava, Svetová vojna, ktoré môžu medzi ľuďmi nastať, a čo v ktorom prípade robiť;
  • Collaboration Conductor – podpora komunikácie ako základu spolupráce v tíme.

Autorka tak skúma pozíciu kouča z viacerých uhlov pohľadov. Každej takejto role venuje niekoľko podkapitol odporúčaných praktík a najčastejších problémov.

Vo zvyšných kapitolách sa snaží Lyssa presvedčiť, že správny agilný kouč musí začať od seba. Že musí absorbovať základné princípy agilného riadenia a žiť nimi. Často krát som mal pocit, že sa dokonca snaží skrz knihu koučovať čitateľa, hlavne pri niekoľkonásobnom opakovaní tej istej myšlienky len inými slovami (čo viedlo k miernemu nárastu objemu knihy, ktorému by sa dalo podľa mňa vyhnúť). Každopádne je v knihe daný silný dôraz na osobný rast a vývoj a skrz neho potom aj na vývoj vašich schopností predať agilné cítenie ľuďom. Zaujímavé sú takzvané úspešné a neúspešné režimy, v ktorých môžete skončiť, ak sa o koučovanie budete pokúšať.

Na záver sa dá povedať, že ak patríte k ľudom, ktorí nemajú agilnými metódami len žiť, ale majú aj poslanie ich šíriť ďalej, tak je toto kniha, ktorá by vás nemala minúť. Po prvé preto, lebo kníh, ktoré sa venujú koučovaniu a agilným metódam nie je veľa (podobná je snáď už len Agile Coaching od R. Davies a L. Sedley) a po druhé preto, lebo problematika koučovania je v nej rozobraná pomerne podrobne, a preto aj skúsený profesionál môže objaviť niekoľko drahokamov medzi riadkami. A ešte jedna myšlienka, ktorá sa mne osobne veľmi zapáčila (z kapitoly o tom, že pri agilných metódach musíte byť schopný prijať zlyhanie a zotaviť sa z neho): The battle cry of a team may be, „If we’re going to fail, let’s fail fast.“

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.

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.

Agilné vzory riadenia I.

Za mojich chlapčenských čias ma vždy fascinovala skladačka Lego. Úžasné na tom bolo, že z jednoduchých kúskov ste mohli postavať čokoľvek. Potrebovali ste len tie správne kúsky a vedieť, čo chcete postaviť. Mohli ste si kúpiť pirátsku loď, postaviť ju, potom ju rozobrať, niektoré kúsky dať nabok a postaviť prístav. Čím menšie tie kúsky boli, tým väčšiu ste mali voľnosť v stavaní.

Keď som sa neskôr počas svojej práce stretol s prvými návrhovými vzormi v objektovo orientovanom programovaní, našiel som v nich opäť rovnaký princíp ako malo Lego. Pomocou jednoduchých prvkov, ako je napríklad dedenie, preťaženie, prekrytie metódy alebo polymorfizmy, je možné vytvoriť veľké množstvo rôzne spolupracujúcich tried, ktoré umožňujú pomerne elegantne riešiť aj zložitejšie problémy.

Príklady takýchto problémov a ich riešení:

Problém: Potrebujem vymieňať niekoľko druhov algoritmov, ktoré realizujú jeden proces počas behu aplikácie na základe určitých stavových premenných.

Riešenie: abstraktná trieda + rozhranie + prekrytie metódy + odvodená trieda x počet rôznych algoritmov = vzor „strategy“

Problém: Potrebujem, aby akcia v systéme bola reprezentovaná objektom (kvôli povoľovaniu, Undo / Redo funkciám a pod.)

Riešenie: rozhranie + agregácie + odkaz na metódu = vzor „command“

Samozrejme použitie vzorov nie je také jednoduché, ako som tu popísal, ale mojím cieľom bolo ukázať, že vzory sú skladačky jednoduchých prvkov, ktoré poskytuje objektovo orientované programovanie za účelom riešenia nejakého konkrétneho problému. Existencia vzorov nie je samozrejme obmedzená len na programovanie, ale dá sa nájsť aj v procese testovania, komunikácií klient-server alebo mimo počítačových vied, napríklad v architektúre alebo medziľudských vzťahoch.

A teraz k agilnému riadeniu. Vezmime si napríklad taký Scrum. Je to metóda, ktorá obsahuje niekoľko agilných praktík (produktový backlog, retrospektíva atď.). Čo sa stane, ak si vypíšem agilné praktiky, ktoré obsahuje, niektoré šktrnem, iné dopíšem a potom to zložím naspäť? No mohol by som dostať Kanban. Scrum s Kanbanom sa totiž prekrývajú v niektorých praktikách, ktoré používajú.

Scrum Na Kanban

A práve to ma viedlo k tomu, že agilná metóda môže byť skladačka. Ako Lego. Môžete jednu metódu rozobrať, niektor súčiastky vymeniť a zložiť inú metódu. Stačí len poznať časti, ktoré máte k dispozícii a vedieť, čo chcete postavíť.

Čo sa týka tých častí, tak nám na začiatok postačí The Big List of Agile Practices od Jurgena Appelo-a (mimochodom, jeho blog www.noop.nl vrele odporúčam). Určite nie je úplný, ale obsahuje aspoň základne veci.

Čo sa týka problému, ktorý má metóda riešiť, tak tu sa vrátime späť k návrhovým vzorom. Ako som písal, tie sú určené na riešenie niektorého konkrétneho problému. Ak mám jasné, o aký problém ide, použijem vzor, ktorý ho rieši. Rovnaký postup by sa dal použiť aj pri výbere metódy riadenia projektu. Stačí si len ujasniť, čo potrebujeme.

Takže napríklad: Máme projekt, kde zákazník bude určite meniť požiadavky, ďalej sa projektu bude účastniť tím, ktorý nie je úplne dobre zabehnutý a na záver projekt nemá veľký rozpočet.

Čo potrebujeme:

  • krátke alebo žiadne sprinty, aby sme vedeli reagovať na požiadavky

  • denné meetingy, aby sme zamedzili chaose v tíme

  • Personas, aby sme neprodukovali niečo, čo nikto nebude používať (t.j. odpad)

Takýmto postupom viem identifikovať agilné praktiky, ktoré v metóde potrebujem, aby som sa vyrovnal s požiadavkami na projekt. Treba si totiž uvedomiť, že praktiky, ktoré sú v metóde obsiahnuté určujú jej vlastnosti. Tieto vlastnosti sú zase vyžadované prostredím, v ktorom sa projekt nachádza (t.j. prístup zákaníka, organizácia a pod.).

Prostredie Projektu

A teda na záver. Ak máme návrhové vzory objektovo orientovaného programovania, ktoré sú na riešenie problémov, môžeme mať aj návrhové vzory agilného riadenia na riešenie projektov. Tak ako pri návrhových vzoroch, by časom mohol niekde vzniknúť zoznam vzorov agilného riadenia, kde by boli vypísané zoznamy agilných praktík, ktoré tento vzor obsahuje a vlastnosti, ktoré daný vzor má.

Praktiky v Jurgenovom zozname môžeme v zásade rozdeliť do dvoch kategórií: procesné a objektové (ceremónie a artefakty). Na to, čo to znamená a aké vlastnosti tieto praktiky prenesú na celú metódu, sa pozrieme v ďalšej časti.

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.

Základy Scrumu

Táto prezentácia je zhrnutím základných techník použitých v Scrume. Ospravedlňujem sa za prezentáciu v angličtine, ale dúfam, že pomôže. Odporúčam Vám si stiahnuť PowerPoint verziu vzhľadom na použité animácie.
Ak máte záujem o podrobnejšie vysvetlenie, kontaktujte ma (dusankocurek at hotmail dot com).

Prečo Agile@Slovakia

Pred troma rokmi som sa začal aktívne venovať Scrumu, ktorý sa mi zapáčil nielen pre svoju jednoduchosť, ale hlavne kvôli tomu, čo som zažil pri jeho reálnom nasadení v praxi.

Ale pozabudol som sa predstaviť. Volám sa Dušan Kocúrek. Som zakladateľ skupiny Agile@Slovakia. Už viac ako 12 rokov pracujem v IT na rôznych pozíciách od vývoja, cez implementáciu a návrh procesov, až po projektový, produktový a operačný manažment tímov.

Ale späť k Scrumu. Tá okamžitá odozva v tíme, to “prebudenie” a aktivita bola jasným príznakom toho, že toto je cesta k zvýšeniu efektivity a vyššiemu vlastníctvu produktu v celom tíme.

Hlavný problém boli informácie ako začať. Ani nie tak informácie ako reálne skúsenosti a rady, o ktoré by sa dalo oprieť a rýchlejšie tak zaviesť Scrum samotný. Predísť tápaniu. Veľkou pomocou bola kniha Henrika Kniberga Scrum and XP from Trenches. Táto kniha plná praktických príkladov názorne ukázala čo to Scrum je a ako ho zapracovať. Na druhej strane otvorila množstvo otázok (ako odhadnúť veľkosť backlogu? prečo vlastne mám použiť veľkosť trička?, čo to je ten storypoint?  atď.)

Úsilie nájsť niekoho na Slovensku, kto by bol ochotný a schopný pomôcť, vyústilo do rozhodnutia vytvoriť skupinu, ktorá spojí ľudí aplikujúcich agilné techniky a vytvorí tak fórum otvorené diskusii, ochote napomôcť a podporiť celú komunitu.

Skupina Agile@Slovakia vznikala najprv len pomaly osobnými kontaktmi, neskôr pokračovala hostovaním na LinkedIn a dnes môžme konečne vyhlásiť, že máme náš spoločný blog. Blog, za ktorý sa musím poďakovať dvom Mariánom – Mariánovi Tkáčikovi a Mariánovi Skalskému.

Agile@Slovakia si kladie za cieľ nielen pasívny prístup, ale pokiaľ to bude možné aj aktívne podporovať členov tejto komunity. Jedným z takých príkladov je podpora účasti na vynikajúcej konferencii v  Kyjeve v októbri 2009.

Týmto blogom chceme umožiť publikovať informácie o Agile všetkým, ktorí majú o to záujem.

Ak máte záujem, kontaktujte ma prosím (dusankocurek at hotmail dot com) a zariadim Vám prístup.

 

Dušan Kocúrek

Agile@Slovakia Founder