Postrehy z open space o roli projektového manažéra v Agile PMO

Novembrové stretnutie v Bratislave sa venovalo zavádzaniu agility v spoločnostiach, kde je ťažké si ju predstaviť.

Vďaka Pavlovi Eliášovi zo Žliny sme mali  možnosť spoznať ako agilita pomohla v distribuových tímoch, ktoré musia v bežnom pracovnom živote dokázať nielen, že sú ekonomicky výhodnejšie, ale že vedia aj skutočne prinášať hodnotu. Pán Eliáš upozornil aj na základné problémy, ktoré agilitu výrazne brzdili a naopak, praktiky, ktoré pomohli. Myslel tým dobré praktiky, nie najlepšie praktiky, ktoré nie sú často prispôsobené realite projektu.

Eva Kišoňová nám ukázala, že agilita nie je o implementácii princípov z kníh. Spoločnosť, v ktorej Eva pracuje, potrebuje spĺňať aj štandardy, ktoré sú v principiálnom rozpore s agilnými princípmi a napriek tomu bolo možné im agile prispôsobiť a zaviesť. Znamená to možno proces, ktorý je komplikovanejší v porovnaní s jednoduchým Scrumom, ale vyhovuje tak tímom aj zákazníkom. Eva ukázala aj to, že agilita nie je iba o Scrum, ale aj o praktikách vývoja, kultúrnych rozdieloch a rozdieloch v chápaní významu terminológie. Že je to o ľuďoch bez ohľadu na miesto, v ktorom pracujú.

Ján Masaryk porozprával o pokuse zaviesť agilitu v spoločnosti, v ktorej pracuje. Po perfektnej prezentácii agility vedeniu spoločnosti sa rozhodli vyskúšať agile v pilotnom projekte. Ako to dopadlo? S množstvom tém na zlepšenie. A zlepšenie v tomto prípade znamenalo hľadanie pomoci zvonku spoločnosti. Pomoci, ktorá má praktické skúsenosti s agile a zároveň bude akceptovaná tímom ako expert na danú problematiku. Takže po prvom pilotnom projekte sa rozhodli adaptovať prístup zavádzania agile a uplatniť ho v ďalšom pilote. S väčšou orientáciou na ciele spoločnosti, nie na cieľ rovnajúci sa zavedeniu agile v tímoch.

Aby agile nebolo cieľom samotným, ale nástrojom pre vyššie ciele, ktoré enterprise spoločnosti umožnia prežiť aj v dnešnom tak globálnom, rýchlom a na ekonomiku náročnom svete.

Po prestávke (a napriek pokročilému času) sme sa v diskusii porozprávali o vízii projektového manažmentu a Agile PMO v agilnej organizácii. Diskusia čiastočne načrela aj do iných tém (kontrakty, soft skills, transformácia spoločnosti,  projekty vo verejnej správe). Táto téma je však v súčastnom stave zavedenia agility na Slovensku ešte priskorá, a aj preto sme sa dohodli sa k nej vrátiť v  budúcom roku.

Postrehy z diskusie o role projektového manažmentu a Agile  PMO:

  1. Prečo nás zaujíma práve rola projektový manažér?
    1. Otázka pri zavádzaní Agile: Kým budem ja?
    2. “Mám sa to pýtať?”
    3. “Nevieme s tým pohnúť”
    4. Je projektový mnažment zábranou v agilite?
    5. Ako premostiť rozdiel kultúr Agile a Vodopád?
  2. Čím sa zaoberá PMO v organizácii?
    1. útvar pre projektových manažérov
    2. Procesy, metodiky
    3. Zdroj ľudí pre organizáciu
    4. Rozhranie komunikácie. V Agile sa javí produktový vlastník ako možná rola.
  3. Kto sa bude zaoberať:
    1. Budgeting
    2. Profitabilita
    3. Financie nenahradíš
    4. Fakturácia klienta
    5. Controlling projektu
  4. Agilita – typické problémy
    1. Agilita vo verejnej správe? Škoda, ešte nie. Práve tam by najviac pomohla.
    2. Zbytočné vytváranie enterprise architektúry do zásuvky.
    3. Veľká úroveň detailu už na začiatku od zmluvnej fázy.
  5. Scrum Master musí byť schopný počúvať
  6. Projektový manažér musí rozumieť produktu/projektu
  7. Scrum Mastra a projektového manažéra spája potreba mť organizačné schopnosti
  8. Scrum Master by mal mať technické znalosti, aby rozumel projektu. V niektorých situáciách sa podľa účastníkov toto ukázalo aj ako nevýhodou, preto si treba zachovať správny odstup.
  9. Vytrhnutie scrum mastra z tímu nefunguje dobre.
  10. Scrum Master by mal byť zžitý s tímom po dlhšiu dobu.
  11. Projektový manažér dostane zadanie a ide.
  12. V Agile je dôležitá biznis hodnota, tradičný projektový manažér však viac sleduje náklady.
  13. Organizačné línie sú pre agilitu prekážkou.
  14. Projektový manažéri by sa mali učiť byť viac biznis a proklientsky orientovaní.
  15. Aj seniorní vývojári sa osvedčili ako scrum mastri.
  16. Najčastejšie sa projektoví manažéri  stávajú scrum mastrami práve kvôli soft skills.
  17. Ak sú projektoví manažéri veľmi blízko klienta, potom je možno lepšie zvážiť ich rolu ako produktových vlastníkov.
  18. Vytvorenie agile PMO ako súčasť transformačného backlogu
  19. Význam PM ako podpora, optimalizácia, metodik, kouč.
  20. Zastúpenie v agilnej pracovnej skupine
  21. Zaoberá sa dobrými, nie najlepšími praktikami.
  22. Hodnoty v organizácii sa výrazne menia.
  23. Strata motivácie sa o seba výrazne postarať.
  24. Agilita vedie k splošteniu organizačných štruktúr.
  25. Najdôležitejšie je s agilitou začať a nebáť sa zmien. Veď práve tie chceme dosiahnuť.
  26. Väčšina PM sú veľmi dobrí v komunikácii s klientom.
  27. Dobrí projektoví manažéri si robotu v agilnom tíme nájdu. Ak nie, tak práve toto poukazuje, že ich nie je treba.
  28. Produktová stratégia by mala byť veľmi blízko PMO.
  29. Ako vzniká autorita?
  30. Pozor na scrum mastrov so silnou osobnosťou, ktorá potláča angažovanosť.
  31. Projektové portfólio na rok dopredu. Áno alebo nie?
  32. Presun tímu k iným scrum mastrom nefunguje.
  33. Rozdelenie zložitých projektov na fázu konceptu a realizačnú.
  34. Techniky musia byť vybrané per projekt, nie ako záväzné nariadenie pre všetky projekty.
  35. Prekonanie viery v pevné rozpočty
  36. Kedy a prečo potrebujeme reporting?
  37. Ako produktový vlastník mám výrazne menej reportov ako potrebujem
  38. Rôzny reporting v závislosti od úrovne.
  39. Nezabíjať scrum mastra s reportingom.
  40. Dohodnúť fix price man days kontrakt na začiatku, potom postupne zaviesť agilitu.
  41. Boj s položkami, ktoré potrebuje pre život. Dnešný trh však tlačí inak.
  42. Téma Agile PMO je dnes na Slovensku ešte predčasná. Porozprávajme sa o nej opäť na budúci rok.
  43. Mení sa ekonomický model fungovania firem? Je ekonimika postavená na nákladoch ešte aktuálna?

Novembrový meetup v Bratislave

V novembri máme ďalší meetup v Bratislave.

Termín: 26.11.2012, 18:00

Miesto: Hotel MaxInn, Pri Suchom mlyne 7, Bratislava

Témou bude agilita v enterprise, korporáciách a firmách s dlhodobo zabehnutým biznisom. Jednoducho o agilite tam, kde je si ju ťažké čo i len predstaviť.

Máte chuť zdiešať vaše skúsenosti? Privítame vašu prezentáciu. Okrem prezentácii bude priestor aj na diskusiu.

Program

  • Príspevky:
    • Eva Kišoňová, Siemens – Ako nezničiť agilný prístup vo veľkých projektoch a veľkej firme
    • Pavol Eliáš, Descartes – Skúsenosti s agilnými metodológiami v prostredí distribuovaných tímov
    • Dušan Kocúrek, ScrumDesk s.r.o. – Agilita nástrojom, nie cieľom
  • Témy pre Open space diskusiu
    • Vizia PMO a projektových manažérov v rámci agilných projektov vo veľkej firme

Vyhrajte vstup na Agile Prague

SDlogorobime_it-logo

ScrumDesk s.r.o. v spolupráci s robime.it a organizátormi konferencie Agile Prague ponúkajú nielen členom Agile@Slovakia  vstup zdarma na konferenciu Agile Prague v hodnote 5.000 CZK!

Čo potrebujete spraviť aby ste tento vstup získali?  Stačí zodpovedať pár jednoduchých otázok o Agile na stránkach robime.it.

Zúčastniť sa súťaže na stránkach robime.it!

logo_apc-250x70

Prečo ísť do Prahy 3.-4. septembra 2012:

  • pretože je to Praha :),
  • pretože stretnete viac ako 100 ďalších ľudí, ktorí aplikujú Agile alebo sa snažia dozvedieť viac,
  • pretože budú predstavené prípadové štúdie z Barclays, CA, IBM, Kerio, Seznam.cz,
  • po každej prednáške bude rečník dostupný v open space zóne. Preberte svoje problémy s expertmi.

Viete kto prezentuje?

a ďalších 24 rečníkov. Mimochodom, poznáte rečníkov na fotografiách? Stretnete ich na konferenciách nielen v Prahe.

Tak a teraz klikni na linku a pokús sa vyhrať!

Fyzický vs. elektronický Scrum

fdsafdsf4564Scrum, ako aj iné metódy riadenia (či už pre tím alebo osobné), vyžaduje určité nástroje na realizáciu. Zoznam, grafy a iné artefakty, ktoré sú pre beh metódy nevyhnutné. Tieto nástroje môžu existovať vo forme elektronickej alebo fyzickej. Elektronická forma predstavuje rôzne špecializované softvéry alebo prispôsobené všeobecnejšie nástroje (Calc, Excel..), zatiaľ čo pri papierovej je to najčastejšie samotný papier alebo tabuľa (magnetická, korková …). Diskusia o tom, ktorá z týchto foriem je vhodnejšia, je prakticky nekonečná a to z jednoduchého dôvodu: univerzálna odpoveď na túto otázku neexistuje. Respektíve existuje odpoveď, ktorá ale nepomáha problém riešiť, a to je: pre každý projekt je vhodná iná forma. Keď už ale príde na lámanie chleba, musíte si vybrať…

To, čo pomáha sa dostať z tohto bludného kruhu otázky a odpovede je fakt, že každá z týchto foriem má svoje výhody a nevýhody. Práve tento zoznam bonusov a potenciálnych rizík by mal byť prostriedok, ktorý umožní zvládať túto dilemu. Je potrebné len zvážiť, ktoré vlastnosti sú pre váš projekt najdôležitejšie a vybrať. Poďme sa teraz bližšie pozrieť na jednotlivé výhody a nevýhody.

Elektronika

Ak sa rozhodnete použivať elektronický nástroj, je výber taký široký, až to začína byť nepríjemné. Vybrať si môžete buď nástroj, ktorý je šitý priamo na vašu metódu, ktorý vám dá presne to, čo potrebujete, ale na druhej strane vás môže obmedzovať, ak potrebujete niečo naviac. Alebo si môžete siahnuť po univerzálnejšom nástroji, ktorý si budete musieť najprv prispôsobiť. Teraz mám na mysli vyššie spomínané nástroje ako Calc alebo Excel, s ktorými viete robiť naozaj veľa, ale chce to vedomosti a čas. Rozdiel medzi týmito dvoma kategóriami je hlavne v tom, že s tým prvým si kupujete aj metódu, s tým druhým nie. Prečo ale po softvérovom nástroji siahnuť:

  1. prístup z rôznych miest – toto je asi najdôležitejšia výhoda. Pre distribuovaný tím je elektronická forma prakticky nevyhnutná. Ale členovia tímu nie sú jediní, ktorých stav projektu môže zaujímať. Riadiaci pracovníci, obchodné oddelenie alebo zákazník. Alebo hoci aj ten monitor vo vstupnej hale, ktorý vysiela Sprint Burnd Down Chart náhodným okoloidúcim.

  2. vyhľadávanie – jednoznačne jednoduchšie ako pri fyzickej forme.

  3. prenositeľnosť – kopírovanie, zálohovanie, dlhodobá archivácia.

  4. ľahký prechod na papier – rôzne grafy a zoznamy je často možno jednoducho vytlačiť a získať tak ich fyzickú formu.

  5. automatizácia – systém dokáže automaticky za vás vykonávať niektoré práce. Kreslí graf, počíta priemery, posiela e-maily…

Fyzické nástroje

Pod pojmom fyzické nástroje si môžete predstaviť akékoľvek jednoduché prostriedky, pomocou ktorých viete v reálnom svete zobrazovať stav projektu. Tabuľa, papier, fixa, pero, nálepka, magnet, lepiaca páska, špagát, žiarovka, siréna atď. S hotovými fyzickými sadami pre Scrum som sa zatiaľ príliš nestretol, ale ak prehľadáte internet, určite nájdete dostatok inšpirácie. Prečo ale siahnuť po fyzickej forme:

  1. sloboda – jednoduché nástroje vám umožnia vytvárať ľubovoľné zložité objekty. Obyčajná popisovacia tabuľa s fixou a sadou lepiacich papierikov poskytuje neuveriteľné množstvo možností kombinácií toho, ako ich dokopy použijete. Niečo nefunguje, tak ako potrebujete? Zahodíte a nahradíte iným riešením. Ak nefunguje ani to, skúsite niečo iné. Takáto sloboda ohnúť nástroj do požadovaného tvaru môže byť pri softvéry problém. A že by mali mať ľudia navrch oproti nástrojom hovorí už aj samotné Agile Manifesto.

  2. hmatateľnosť – svet softvéru alebo poskytovania služieb má oproti klasickej priemyselnej výrobe jednu nevýhodu – to, čo firma vyrába, s čím sa každý deň pracuje, nie je hmatateľné. Na prvý pohľad to nemusí vyzerať až tak podstatne, ale je dôležité si uvedomiť, že spoločnosť za posledné desaťročia prešla revolúciou, zatiaľ čo my ľudia sme skôr evolučná záležitosť. Hmatateľné predmety je možné si podávať, rozostavovať ich v priestore, ukladať na kopy alebo hoci aj hádzať do koša. Všetko toto sú pre ľudí prirodzené činnosti, preto aj práca s fyzickými nástrojmi je prirodzenejšia.

  3. jednoduchšia viditeľnosť – ak sa nerozhodnete pre nejaké komplikovanejšie riešenie ako je zapnutý projektor, alebo každodenné tlačenie stavu na papier má elektronická verzia jednu nevýhodu – je uzamknutá do vášho monitoru. Oproti tomu je fyzická často umiestnená na nejakom viditeľnom mieste, a teda je omnoho ťažšie ju prehliadnuť (pre vás, manažment alebo kohokoľvek, koho by to mohlo zaujať). Stačí len otočiť hlavu.

Myslím, že rozhodnutie o forme by malo padnúť pre každý projekt zvlášť a dokonca, že by malo byť možné ho zmeniť, ak sa ukáže, že druhá forma je vhodnejšia. Každopádne je možné tieto formy udržiavať aj obe naraz – synchronizovať. To si ale vyžaduje viac úsilia, a teda je otázne či to naozaj stojí za to. Takto sa síce dajú získať výhody obidvoch foriem, ale zaplatíte za to monotónnou každodennou prácou a rizikom, že sa synchronizácia rozíde.

Meetup v Banskej Bystrici

Meetup sa bude konať o jeden týždeň neskôr ako bolo pôvodne oznámené!

BB

Agile v Banskej Bystrici? Dúfame, že áno!

Pozývame Vás na ďalšie stretnutie Agile@Slovakia.

Prídťe:

  • počuť o iných prístupoch, ktoré sa stávajú štandardom riadenia projektov nielen v IT,
  • zistiť ako začať s Agile,
  • spoznať ľudí z Vášho okolia, ktorí Vám môžu pomôcť
  • porozprávať sa o Vašich prístupoch a problémoch pri používaní Agile
  • prezentovať Vaše myšlienky a skúsenosti

Kedy: 28.5.2012, 4.6. 2012 18:00

Miesto: Hotel Penzión Kúria, Bakossova ul. 4, Banská Bystrica

Ako bolo na Open Space Meetup v Bratislave

V utorok 2.4. sa v Bratislave stretli ľudia aplikujúci alebo zaujímajúci sa o Agile. Tentokrát sme sa rozhodli venovať iba diskusii a rozhovorom s cieľom spoznať prístupy iných tímov.

Tu je zoznam diskutovaných tém a postrehy z diskusie. Ďakujeme za toto neuveriteľné množstvo postrehov v priebehu pár hodín.

Fixná cena projektu a Scrum

  • Chceme sa zbaviť fixnej ceny
  • Fixná cena veľkých projektov (2 roky)
  • Použitie MoSCoW prioritizácie ako možnosti pre identifikáciu vlastností, ktoré zákazní ľahko oželie, resp. termínovo posunie
  • Zmluvy niektorých spoločností obsahujú aspoň % možného oneskorenia termínov
  • Fixná cena spôsobuje dlhú prípravu a podrobnosť zmluvy
  • Diskusia o nových systémoch  (presná cena, dátum, rozsah) alebo údržbu (možný scrum)
  • Stanovenie ceny na konci analýzy, niektoré spoločnosti robia analýzu v samostatnom sprinte, na konci ktorého sa stanový rozsha a následne cena
  • Fixná cena spôsobuje často drastické zmeny v internej implementácii produktu, čo vedie k zhoršeniu kvality produktu
  • Modul v extra platbe
  • Ako aplikovať Agile na subdodávateľov?
    • Zahrnúť ich do agilného tímmu na dennodennej báze ako regulárnych členov tímu
    • denné scrumy
    • spoločné plánovanie, retrospektíva a demo
    • Dávate pokuty? Ako sa vyvíjajú vzťahy?
  • Odporúčané postupy z Ganthead.com: počet iterácií, výkonnostné ukazovatele, cieľové náklady, rozsah a stanovenie min-max ceny, pevný počet iterácií, lean

Nové požiadavky – prijať alebo neprijať?

  • Rozdiel či požiadavky prichádzajú do produktového alebo sprint backlogu
  • Rozdiel či ide o funknčnú požiadavku, zmenovú alebo chyby
  • Väčšina preferuje neprijať požiadavku do sprint backlogu
  • V sprinte robíme barter, ak je niečo pridané, niečo iné musí zmiznúť
  • Reprioritizácia ako výhoda pre klienta
  • Sprint chceme mať pevný, zamknutý

Dĺžka sprintov

  • Podľa čoho nastaviť dĺžku sprintov?
  • Zvyčajne sa používajú 1,2,3 týždne
  • 1 mesiac sa ukázal ako málo agilný
  • Problém s posledným týždňom, ak je v sprinte menej práce
  • Plánovanie robíme celý deň
  • Dlhší sprint je lepší pre retrospektívu

Snáď sme Agile

  • Estimácia iba časti produktového backlogu
  • Hotová časť produktu vedie k spokojnosti tímu a zákazníka
  • Nezaujímajú nás hodiny, ale výsledok
  • Ako plánovať a prezentovať prácu na backend-e?
  • Práca na backende musí byť prepojená s frontendom, vytváranie požiadaviek pokrývajúcich celú vertikálu
  • Ako robiť demo ak klient je v zahraničí?
  • 100% priradenie ľudí v tíme na prácu na jednom projekte
  • Je Scrum of Scrum riešením problémov viacerých tímov?
  • Aký je dobrý pomer vývojárov a testerov v agilnom tíme?
  • Multidisciplínny tím je jednoznačne výhodou
  • Zdieľanie ľudských zdrojov medzi viacerými scrum tímami ak ide o špecialistov
  • Robíme FREE  FRIDAY, potom je retrospektíva ľahšia a hodnotnejšia

Scrum mimo softvérového vývoja

  • Digitálna produkcia
  • Automotive
  • Operation
  • ZOH Vancouver
  • Organizovanie eventov, koncertov

Párové programovanie

  • Robí iba jedna spoločnosť
  • Rozhodnutie kto robí párové programovanie s kým
  • Zostavnie dvojíc dobrovoľne
  • Zohľadnenie kapacity
  • Podpora Scrum mastra

Support vs. vývojový tím

  • Kedy odovzdať funkčnosť?
  • Chyby a dĺžka sprintu
  • Investícia do testovania zmenšuje nutnosť supportu
  • Plánovanie opráv chýb v sprinte
  • Kapacita a skúsenosti ľudí
  • % kapacity chyby vs. funkčnosť
  • Tímy hasičov

Klient a Agile tím

  • Aj klienta je treba naučiť agile
  • Funkčný softvér výhoda
  • Ukazujeme funkčnosť
  • Vyššia dôvera
  • Kontrola vs. odovzdanie, akceptácia
  • Učíme ich “pádom” aplikácie

Iné

  • Máme vytvorenú definíciu HOTOVO
  • Metriky pre odhad nasledujúcich sprintov
  • Rátame iba reálne ukončené a akceptované produktovým vlastníkom
  • Ako transformovať spoločnosť na agile spoločnosť?
  • Vzťah agilných a neagilných tímov v spoločnosti
  • Čo je nasaditeľná verzia?

Projektový manažér == Scrum Master?

V posledných dňoch mám čoraz väčší dojem, že niektoré veci musíme ako komunita dôraznejšie ozrejmovať,  vysvetľovať a trvať na správnom použití.

V tomto príspevku sa chcem viac zamerať na význam roly Scrum Master. Prečo? Pretože počas posledného týždňa som našiel päť článkov (jeden dokonca publikovaný na nemenovanej unverzite), ktoré nesprávne vysvetľujú kto je Scrum Master, čo má robiť a ako to má robiť.

Dôvodom je možno slovenčina, do ktorej sa tento pojem Scrum Master veľmi ťažko prekladá. Majster Scrumu? Hmm, v profesionálnom prostredí to znie zvláštne. Ja osobne tento pojem práve preto takto neprekladám. No významovo je tento preklad vynikajúci.

Projektový manažér (v terminológii Scrum-u „ScrumMaster“)

Chcel by som sa venovať asi najväčšiemu nepochopeniu, ktoré som objavil.

Nie, nesprávne. Toto sú dve roly, ktoré majú za úlohu riešiť iné aspekty. Áno, často je to ten istý človek. No tento človek má na vešiaku dva kabáty. Raz môže byt projektovým manažérom, inokedy scrum mastrom. Dokonca z praxe poznám mnohých projektových manažérov, ktorý sa radšej stali Scrum Mastrom.

Prečo? Pretože  Projektový manažer <> Scrum Master.

Pretože projektový manažér sa má zaoberať časom, rozpočtom, zdrojmi a kvalitou. To sú atribúty akéhokoľvek projektu. A projektový manažér ich má držať pokope tak, aby výsledok projektu bol dodaný načas, v rozpočte s danou kvalitou, vyvinutý vybraným tímom.

Projektový manažér je na svete kvôli PROJEKTU.

No Scrum Master sa týmto primárne vôbec nemá zaoberať. Scrum Master sa zaoberá:

  • Vyrovnávaním cesty, po ktorej kráča tím.
  • Snaží sa skoro rozpoznať prekážky, snaží sa ich odstrániť aj za pomoci organizácie.
  • Snaží sa tímu pomôcť, aby bol efektívnym.
  • Robí denne prácu, ktorá by iných blokovala.
  • Prináša a udržuje viditeľnosť stavu projektu tým, že komunikuje s tímom a inými tímami
  • Synchronizuje tím s inými tímami
  • Pripravuje a moderuje (pozor, nevedie!) porady a diskusie.
  • Komunikuje s organizáciou – produktovým aj projektovým manažérom.
  • Zaoberá sa procesom vývoja.
  • Koučuje (vyučuje) agilné techniky v tíme. Také aké práve tímu pomôžu. Musí mať prehľad o tejto problematike a mal by vždy vedieť trochu o tom viac ako členovia tímu.

Scrum Master je na svete kvôli TÍMU.

Máte na tento zoznam ako projektový manažér v dnešnej dobe čas?

Fedexday

124f54gNáklady firiem na vytváranie motivácie u zamestnancov nie sú malé. Obľubené sú teambuildingové akcie, výlety, finančné prémie a pod. To všetko stojí peniaze. A pritom čínnosť ako je vývoj softvéru (a vývoj všeobecne) môže byť sama o sebe natoľko zaujímavá, že sa stáva motiváciou. Ak neveríte, dá sa to jednoducho overiť. Môžete si skúsiť Fedexday.

Pre zamestnancov je Fedexday zážitok, pre zamestnávateľa sa to nedá nazvať inak ako veľa muziky za málo peňazí. Fedexday je súťaž, kedy za 24 hodín (preto ten Fedex v názve) musíte vyvinúť a dodať (t.j. musí to byť funkčné) nejaký výsledok. Pre softvérové firmy to znamená hlavne dodanie softvéru. To, na čom budete pracovať, akú technológiu použijete a s kým na tom budete pracovať, je na vás. Práve táto sloboda venovať sa niečomu, na čo ste si už možno dlho brúsili zuby, je hlavným motorom akcie. Je to síce súťaž a na konci je vyhlásenie víťaza, ale žiadne reálne vecné ceny nečakajte. Tie by len poškodili hlavnú motiváciu a tou je zvedavosť a snaha niečo dokázať. Fedexday neznamená len, že môžete robiť, na čom chcete, ale aj to, že máte na to 24 hodín a nie viac. Za ten čas musíte byť schopný dodať to, čo ste si predsavzali.

Pred určitým časom som sa takejto akcie zúčastnil a myslím si, že je to niečo, čo je prospešné pre firmu aj zamestnanca naraz. Zamestnanec môže zažiť nevšednú akciu, pri ktorej si otestuje novinku alebo vytvorí niečo, po čom už dávno túžil. Firma zase za malý obnos (poskytnutie priestorov, pizza) u ľudí zvýši motiváciu k práci. Začať pracovať na obed jedného dňa, pracovať 24 hodín bez oddychu a na ďalší deň opäť na obed to prezentovať je zážitok, ktorý možno nie je až taký adrenalinový ako skok s bungee lanom, ale má svoju osobitosť. Jedna z vecí, ktorú vás to naučí je, že ste schopný dodať hotovú vec za kratší čas, ako ste mysleli. Pritom prostredie ani nástroje sa nemenia. Len vaša motivácia.

Fedexday vie byť pre firmu pomerne silným impulzom. Je podľa mňa lepší ako štandardná teambuldingová akcia, pretože ľudia si vyberajú, čomu sa budú venovať, a teda sú do toho viac zapojení ako do nejakých súťaží, ktoré niekto pripravil. Tímy sa formujú sami, myšlienky sa realizujú v krátkom čase a učiaca krivka je prudká. Po 24 hodínach máte dosť. Ste zrelý na sprchu a do postele. Ale kombinácia toho, že ste sa za tak krátky čas prehrýzli problémom a dodali niečo čo funguje, že ste pochopili, ako to máte celé postaviť a potom to postavili … to jednoducho stojí za to.

Simulácia Scrumu s LEGO kockami

Alexej Krivitsky, agile kouč a organizátor známej konferencie Agile Eastern Europe, už dlho učí Scrum pomocou hry LEGO.

Pomocou tejto hry je možné veľmi názorne a prakticky pochopiť ako má agilný tím fungovať, ako plánovať produkt a ako sledovať priebeh pomocou Scrum.

Keďže túto hru hrajem aj ja pri našich agilných tréningoch, Alexej ma poprosil o preklad do slovenčiny. Ďakujem Tiborovi Radačovskému za pripomienky.

ScrumLego

Stiahnite si slovenskú verziu.