Tag Archives: Agile

Úlohy alebo aj niečo viac?

Posted on by

Projektový manažment je o ľuďoch, peniazoch a produkte. Tieto tri časti reprezentujú úlohy. Sú ale úlohy postačujúce?

Náš život je riadený úlohami

Aj vy to tak pociťujete? Taká úloha je často definovaná ako odpoveď na otázky:

  • Čo?
  • Kto?
  • Ako?
  • Ako dlho?

Projekty sú tak tvorené množstvom úloh, ktoré navyše navzájom komplikovane súvisia. Navyše úlohy sú vytvárané v projekte veľmi skoro, už počas tvorby projektového plánu kedy nie je celkom jasné čím daný projekt je, kto ho bude riešiť a aký je rozpočet. Skoro nič nie je isté. Poznáte to aj Vy?

Vo firmách, ktoré sú riadené iba úlohami často postrehnete určitý vzor chovania.

Ľudia si ráno typicky otvoria ďalšiu úlohu (v nejakom elektronickom systéme) a keď je dokončia, tak (v lepšom prípade) ju uzavrú a otvoria si ďalšiu. Pracovný život sa tak časom zmení na cyklus OTVOR-VYRIEŠ-UKONČI. Tím zrazu po nejakej dobe nevie odpovedať na otázku PREČO?. Stráca sa tak poznanie produktu, zákazníka a jeho potrieb. Stráca sa tak chápanie prvotných príčin prečo je vlastnosť potrebná, chápanie kontextu riešeného problému. A tieto straty mňa, produktového manažéra, by mali trápiť. Veľmi. Priam bolieť. Tím dokonca nerozumie pre koho vyvíja a ako je to dôležité pre vašu firmu. Ako to zmeniť?

Stories

Prepáčte, že použijem anglický termín, ale zatiaľ som dobrý preklad do slovenčiny nenašiel. ‘Príbeh’ mi v tomto prípade znie čudne.

Story je požiadavka. No, nie tak celkom, ale v podstate sa tak dá chápať.

Požiadavka, ktorá je náročky v agilnom projekte zapísaná inak. Jednoducho a prehľadne. Na kartu, s ktorou sa dá manipulovať. Story je zapísaná v tejto forme:

 

 

Príklad (a môj odkaz pre Zajtra.sk :))

 

Rozdiely voči úlohe? Story jasne popisuje kto, čo a hlavne prečo to potrebuje. Tým, že je popis stručný, je aj požiadavka pomerne presne popísaná a je navyše malá rozsahom. A teda ľahko manažovateľná. Dá sa pomerne ľahko určiť kto je schopný story riešiť a ako dlho bude trvať jej riešenie. Dá sa ľahko implementovať v krátkom časovom intervale a sledovať jej priebeh.

Všimnite si veľmi dôležitú vec. Story nepopisuje AKO problém riešiť. Prečo? Lebo človek, ktorý požiadavku zadáva to nevie. A ani by nemal chcieť vedieť. Nato tu máme lepších expertov, vývojový tím.

Backlog

Bohužiaľ ďalšie anglické slovo. Backlog je utriedeným zoznamom stories.
Na rozdiel od zoznamu úloh je tak backlog popisom produktu, nie činností a aktivít. Tento zoznam nie je len utriedený, ale navyše stories sa líšia v detailoch popisu. Čím dôležitejšie tým presnejšie. Tie najmenej dôležité sú často popísané iba titulkom, napr. Finančná analýza

Backlog je spravovaný produktovým vlastníkom. Iba on určuje dôležitosť, poradie, stories v backlogu. To on pridáva detaily tak, aby najdôležitešie úlohy boli popísané čo najpresnejšie. Tak aby vývojový tím ich vedel implementovať.

Hey dude, where is my backlog?

Kde je backlog v agilnom projekte? No predsa na tabuli! Všimnite si prvý stĺpec s názvom Product backlog. Všimli ste si to keď ste čítali minulý diel o viditeľnosti?

Každá sivá kartička popisuje story. Potrebujete zmeniť prioritu? Presňte kartu vyššie alebo nižšie. Na základe čoho? Na základe obchodnej hodnoty vlastnosti.

Tipy

  • Story by mala byť implementovaná maximálne počas polovice iterácie.
  • Story by mala mať aj akceptačné kritéria. Tie sú malým kontraktom. Zvyčajne zapísané počas plánovacích mítingov spolu so zákazníkom, produktovým vlastníkom a tímom.
  • Nezaoberajte sa odpoveďami na otázku AKO. V Scrume budete mať inú príležitosť kedy sa to spýtať. Nie pri definovaní produktu.
  • Story je buď dokončená alebo nie. Neakceptujte Dokončená na 90%. Už len 2 minúty.
  • Dokončená môže mať rôzny výklad. Dohodnite sa čo znamená HOTOVO.
  • Detaily v popise story pridávajte tak NESKORO ako sa dá. Predpokladajte zmenu. Ušetrite čas, ktorý strávite pri podrobnej špecifikácii požiadavky na vývoj. Aj tak sa požiadavka zmení.
  • A na záver najdôležitejšie. Každú novú požiadavku zapíšte na papierik a roztrhajte ho. Pretože iba 20% vlastností je použitých užívateľmi aplikácií. Ostatné je nepotrebný odpad.

Linky

Článok bol publikovaný na Zajtra.sk

Viditeľnosť v projekte je kľúčová

Posted on by

Sledovanie úloh, ich priradenia a progresu je v klasickom manažmente zväčša úlohou projektového manažéra. V agile/scrume je to ale úloha celého tímu. Prečo? Lebo manažment agilného projektu je založený na spolupráci ľudí (viď Roly).

Kľúčom je viditeľnosť, pretože podporuje dôveru klienta, manažmentu a aj ľudí v tíme samotnom. Koľkokrát ste mali pocit, že robíte podstatne viac ako kolega sediaci vedľa Vás? Je to ale skutočne tak? Projektový manažéri možno majú prehľad, no často táto viditeľnosť chýba na úrovni tímu.

Tabuľa

Zabudnite na Microsoft Project. Viditeľnosť projektu pre všetkých v ňom nie je možná. Použite jednoduchú tabuľu rozdelenú na viacero stĺpcov. Každý stĺpec popisuje stav úlohy.

Obrovskou výhodou je, že Vám stačí len letmý pohľad a okamžite viete stav projektu.

  • Máte viac papierikov na ľavej strane? Pravdepodobne je toho pred Vami ešte veľa.
  • Je veľa papierikov v strede? Máte veľa vecí otvorených. A je ich dokonca viac ako členov tímu? Pravdepodobne by ste si mali prečítať niečo o Getting Things Done (GTD).

Navyše ak takáto tabuľa je v miestnosti, v ktorej je aj tím, tak zmenu, resp. progress, v projekte postrehnete už len periférne keď kolega vstane a presunie papierik.

Distribuovaný tím?

Hmm, pre distribuovaný tím nebude asi jednoduché dosiahnuť takýto vizuálny manažment.

Niektorí sa snažia tabuľu fotiť, potom fotky posielať alebo zdieľať cez wiki do inej lokácie. Výsledok? Nepoužiteľné, pretože vidíte iba rozloženie papierikov, nie detaily. Jediným riešením je dobrá elektronická aplikácia.

Stačí vidieť a byť videný?

Nie, nestačí. Ak by manažment projektu mal byť iba v presúvaní papierikov, tak v podstate nemáte tím.
Základom je komunikácia. Scrum preto odporúča jednoduchú techniku nazývanú denný standup:

  • Tím sa stretne pred tabuľou každý deň v ten istý čas, ktorý vyhovuje všetkým.
  • Každý člen tímu má jednu minútu na zodpovedanie troch otázok. Len jednu minútu nič viac. Čas je najcennejším.
  • Na čom som pracoval včera?
  • Na čom budem pracovať dnes?
  • Aké mám problémy?
  • Potrebujte prebrať viacero detailov? Pokračujte na inej porade a len tí, ktorí majú čo povedať. NIe celý tím.

Zo začiatku vám to bude pripadať ako ďalšia zbytočná porada, ale pri dobrej organizácii je tento míting veľmi efektívnźm spôsobom zdieľania informácii o stave projektu. Najdôležitejšie pre mňa pri tomto spôsobe je, že mnoho informácií vám prejde cez hlavu. Informácie, ktoré sa vynoria v momente keď ich budete potrebovať. Tzv. AHA moment.

Tipy

  • Papierik presúvajte v momente, keď sa mení stav úlohy, nie raz týždenne.
  • Použite rôzne farby pre rôzne typy úloh.
  • Niektoré tímy používajú farbu podľa toho, kto na úlohe pracuje. V agilnom projekte ale chceme mať tím multidisciplínnym, a preto ja osobne to neodporúčam.
  • Indikujte problémy s úlohou vizuálne. Pripnite farebný špendlík, resp. malý červený papierik.
  • Rôzne tvary zlepšia prehľad.
  • Rozdeľte stĺpce na viacero stĺpcov ak váš process je komplikovanejší.
  • Vyhradťte si čas tabule na tzv. parking lot. Parkovisko úloh, ktoré tím nie je schopný samostatne riešiť, resp. nie je zatiaľ jasné čo s úlohou.
  • Tabuľa nie je len pre IT projekty. Obrázok hore zobrazuje úlohy operation tímu.
  • Vytlačte si malé fotky alebo avatarov reprezentujúcich členov tímu. Urobte niečo pre rozveselenie.
  • Používate dovolenkovú aplikáciu? Dajte fotky dovolenkujúcich do samostatnej časti tabule. Jendoduché nie?

Užitočné odkazy

A nakoniec otázka, ktorú by ste sa mali spýtať pred odchodom z práce.

Článok bol publikovaný na http://www.zajtra.sk/zivot/340/manazment-projektu-inak-klucom-je-viditelnost.

Manažér v dobe Agile

Posted on by

V posledných týždňoch sa stretávam s manažérmi, ktorí sa zaujímajú o Agile. Záujem nepramení možno ani tak z chute ho nasadiť ako skôr z obáv z jeho nasadenia.

Otázka, ktorá je najčastejšia po školeniach je: “Kde je v Scrum-e manažér? Znamená to, že nie som potrebný?”. Tvrdá odpoveď  je, že časom nebudete potrební. Táto odpoveď je tvrdá, ale pravdivá. Na prvý pohľad a počutie to pre manažéra automaticky znamená, že Agile je pre neho ohrozením.  Túto prvotnú a často hlavne emotívnu úvahu však nenasleduje dôležité zamyslenie sa.

 “Čo môžem, z mojej pozície, robiť v agilnom tíme?”  A možno ešte lepšia otázka: “Ako môžem pomôcť agilnému tímu?”

Manažér typicky potrebuje dokončiť činnosti, ktoré v agilnom tíme zrazu môžu robiť,  iné roly.

Činnosť

 Typicky

Agilný tím
Reportovanie Týždenne
Excel 		 Denne
Scrum board
Burn Down graf Celý tím 
     
Plánovanie Manažér plánuje typicky sám, neskôr ďalší skomentujú plán. 
Odhadovanie úloh robí typicky manažér.		 Produkt je plánovaný celým tímom. Každý sprint je plán upravený podľa aktuálnych požiadaviek. 
Odhadovanie úloh je tímové (planning poker).Celý tím 
     
Manažment zdrojov Projektový manažér je zopodvedný za manažment zdrojov.
Manažér ľudských zdrojov najíma/prepúšťa ľudí. Požiadavky sú zvaäčša dané projektovým manažérom.		 Tím identifikuje požiadavky na nové zdroje. Vybraní členovia  tímu sa zúčastnia prijímacích pohovorov a vyberú kandidátov, ktorí tímu pomôžu.Manažér ľudských zdrojov pomôže tímu s legislatívou a pod. 
     
Identifikácia rizík  Projektový manažér  sleduje možné riziká a snaži sa im predísť. Tím identifikuje riziká, Scrum Master riziká sleduje a pomáha tímu. Tím 
     
Odmeňovanie  Team leader, projektový manažér [Kontroverzné] Tím rozdeľuje tímovú odmenu 
     
Obchodné ciele, vízia a stratégia  Zákazník je kontaktovaný obchodnou zložkou, s ktorou uzavrie kontrakt bez komunikácie s realizačným tímom. Pevný dátum, rozsah a cena.Vízia a stratégia je zväčša nemenná. Zákazník je začlenený do realizačného tímu. Kontrakt je často daný na iterácie s možnosťou zníženia v prípade neodkončenia/odmeny v prípade ukončenia väčšieho rozsahu. Vízia a stratégia sa prispôsobuje požiadavkám a situácii na trhu.Produktový vlastník
     
     

Tento presun veľkej časti zodpovednosti samozrejme pre manažéra znamená viac možností sa venovať inému typu práce.  

Čím iným sa teda môže manžér zaoberať?

  • Leadership tímu –  konečne budete mať viac času sa venovať rozvíjaniu sa v tejto oblasti
  • Rozvoj ľudí – práca s ľudmi, ich kariériou
  • Tréningový program – zdieľanie vedomostí, nové technológie, rozvoj ľudí smerom, ktorý je potencinálne prospešný pre budúcnosť spoločnosti
  • Komunikácia v organizácii – aj agilné tímy potrebujú zástupcu v organizácii.

Samozrejme to nie je všetko…. No nezabudnite predtým, než sa rozhodnete s niečím pomôcť, spýtať sa PREČO a PRE KOHO je danná činnosť potrebná. Možno je to odpad (waste podľa Lean).

Agilné testovanie? Prečo nie.

Posted on by

agile.testingAgilný tím by mal byť multiprofesný. Okrem architektov a staviteľov, ktorí ťažko pracujú a budujú produkt, by mal obsahovať niekoho, kto povie, že sa program dá používať. Niekoho, kto sa pozrie na celú vec z inej perspektívy a nájde chyby, ktoré možno z tej pôvodnej nebolo vidno. Niekoho, kto stojí na polceste medzi programátormi a zákazníkmi, a tak sa vie najlepšie dorozumieť s obidvoma skupinami. Tušíte správne, že ten niekto je tester. Aspoň tak ho vidia Lisa Crispin a Janet Gregory v ich knihe Agile Testing.

Hneď na začiatku treba povedať, že kniha by sa dala rozdeliť na dve časti. Jedna sa týka vysvetľovania agilných metód ako takých. Rozoberané sú jednotlivé praktiky aj dôvody prečo ich používať. Tá druhá má za cieľ ukázať ako v prostredí týchto metód testovať. Teda zaoberá sa už len priamo testovaním. Dobrá správa je, že kniha má dosť strán (533), a teda obe polovice dostali dosť priestoru. Zlá je, že sa tieto dve časti knihou postupne preplietajú, a tak si neviete prečítať jednu alebo druhú podľa toho, čo vás zaujíma.

Autorky vidia testera ako veľmi dôležitú časť tímu. Hneď v prvých kapitolách, kde vysvetľujú agilné metódy, sa snažia presvedčiť,  že tester môže byť iniciátorom aj katalyzátorom zmeny riadenia na agilné. S veľkou časťou týchto myšlienok som sa už stretol vo forme pre programátorov, to ale netratí na ich cene v tejto knihe. Nechýbajú klasické témy ako: metriky, spôsob zaznamenávania chýb, plánovanie a spolupráca s požadovanými štandardmi.

Druhá časť knihy je venovaná takzvaným štyrom kvadrantom testovania. Tieto kvadranty sú vytvorené kombináciou možnosti, či ide o testy na podporu tímu (t.j. zvýšenie kvality produktu) alebo kritiku produktu (t.j. vylepšenia používania) s možnosťami, či ide o technické testy (testy stability, škálovateľnosti atď.) alebo skôr obchodné testy (testy procesov, používania). Dá sa povedať, že všetka práca testera v agilnom tíme spadá do niektorých z týchto kvadrantov. Pre každý kvadrant Lisa a Janet uvádzajú zoznam postupov a nástrojov, ktoré môžu byť pre neho použité. Priznám sa, že silu tejto myšlienky som pochopil až na druhé čítanie, ale o to silnejšia mi pripadá. Zatiaľ v žiadnej knihe som nevidel tak jasne a rozumne rozdelenú prácu testera s pomerne kvalitným popisom. Dokonca každý kvadrant obsahuje kapitolu o tom, čo môže tester robiť, ak tím testy v danom kvadrante vôbec nepoužíva.

Ďalšia pomerne veľká časť je venovaná automatizácii. Obsahuje štandardné zoznamy dôvodov, prečo automatizovať testovanie, zoznamy nástrojov, ktoré sa dajú použiť ako aj menej časté témy ako napríklad, čo sa automatizovať neoplatí alebo ako naštartovať automatizáciu už v bežiacom projekte. Odkaz autoriek v tejto časti je jasný: „Čo sa dá, to automatizujte.“

Posledná časť knihy by sa dala označiť ako „sprievodca testera v agilnom tíme“. Postupne sú rozoberané jednotlivé fázy od plánovania releasu/sprintu, cez samotný beh iterácie až po nasadenie. Autorky sa snažia vysvetliť, čo je hlavnou zodpovednosťou testera a o čo sa má snažiť. To snaženie nie je len tak, pretože na niekoľkých miestach v knihe som sa dočítal radu, že ak vás ako testera nezavolajú napríklad na plánovacie stretnutie, tak sa tam proste dostavte a všetkým vysvetlite, že tam musíte byť.

Ako som už spomenul skôr, pozícia testera je brána s plnou vážnosťou ako seriózna inžinierska rola v tíme. Celou knihou sa preplieta myšlienka, že tester je ten najlepší komunikátor medzi zákazníkom (alebo doménovým expertom) a programátorom. Hovoria tomu „sila troch“ a tvrdia, že ak sa má riešiť nejaký problém, tak len vždy v takejto trojici. Osobne s takýmto striktným prístupom nemám skúsenosti ale v mnohých bodoch, na ktoré je v knihe poukázané, sa s Lisou a Janet zhodneme. Každopádne kníh, ktoré by sa venovali priamo agilnému testovaniu nie je až tak veľa, aby Agile Testing nestálo za prelistovanie.

Agilná transformácia formou hry

Posted on by

Keď pred pár týždňami nás kontaktoval Zsolt Zsuffa z Budapešte ohľadom participácie na Agile Meetupe, ponúkli sme rôzne témy krátkeho školenia. S prekvapením sa však Zsolt priamo spýtal na agilné hry. Zaujali ho naše skúsenosti a výsledky a tak chcel skúsiť touto formou stmeliť aj agilnú komunitu v Maďarsku. Pre nás to bola možnosť konečne po prezentáciách urobiť aj niečo praktické, čo ľudia budú môcť vyskúšať aj vo vlastných firmách.

Prechod na agilné technológie je  v dnešnej dobe aktuálnym v mnohých spoločnostiach. Spoločnosti sú zväčša zamerané len na výsledky, ktoré sa dajú merať. V mnohých prípadoch však chýba niečo oveľa dôležitejšie, čo agile priam vyžaduje – zmena myslenia. Táto zmena vyžaduje čas a skúsenosti. Nedá sa naučiť, musí sa zažiť. Je to dospievanie. V takomto prípade je zlyhanie dokonca cennou skúsenosťou, ktorú chceme zažiť často a skoro, hlavne ak ste na začiatku transformácie.

Agilné hry sa stávajú (podobne ako v živote dieťaťa) katalyzátorom vývoja a stávajú sa tak lepidlom ktoré prepája teóriu s praxou. Sú možnosťou ako sa naučiť robiť agile na príkladoch. S pomocou kouča takto tímy nemôžu zlyhať pri učení ako agile robiť.

Hry hrajeme počas tréningov na Slovensku aj v zahraničí už niekoľko rokov. V Budapešti sme sa zamerali na hry vybrané pre transformáciu spoločností na agile:

  • vytvorenie tímu a jeho samoorganizácia
  • pochopenie problémov a zvyraznenie ich podobnosti v celom softvérovom priemysle
  • identifikácia dôvodov prečo agile vzniklo
  • naučenie sa ako robiť agile, ako pracovať v časových iteráciách, ako samoorganizovať nielen tím, ale aj prácu, prečo je jednoduché zadanie požiadavky často efektívnejšie než dlhé dokumenty
  • ako sa zlepšiť použitím retrospektívy

Originál viď ScrumDesk: Serious Play – accelerate your transition to Agile

Agile games (for Budapest meetup)

View more presentations from ScrumDesk.

Agile Eastern Europe 2010 is near!

Posted on by

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.

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

Posted on by

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)

Posted on by

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.