Tag: Scrum

Scrum hra

Plánujete školení Scrum metody a přemýšlíte, jak nejlépe zajistit aby si účastníci co nejvíce zapamatovali? Kolikrát jste se vrátili z kurzu a školení, nadšeni jaké to bylo zajímavé, a už po několika dnech jste vlastně nevěděli, o čem to bylo. Říká se, že lidé se nejvíce učí z vlastní zkušenosti a prožitku. Testy na toto téma uvádějí, že si člověk zapamatuje jen přibližně 20 % z toho, co slyší, a pouhých 30 % z toho co si přečte nebo je mu názorně ukazováno. Ale již 50 % informací si zapamatuje, pokud má možnost nabízené informace vidět i slyšet. Kolem 70 % informací si pak člověk zapamatuje, když má možnost něco vidět, poslouchat a následně o tom navíc hovořit. Pokud k těmto třem činnostem přiřadíme ještě možnost aktivního vykonání, získáváme až 90 % šanci si dané informace zapamatovat [Soňa Hermochová, Teambuilding; Grada, 2006]. Tedy chcete-li naučit někoho Scrum, musíte mu vysvětlit jak na to, ale to nestačí. Aby to celé mělo smysl, musí si účastníci Scrum vyzkoušet na vlastní kůži a zpětně zhodnotit jak jim to šlo, co bylo dobré a co by měli naopak příště vylepšit.

Her se dá hrát mnoho, mohou být různě složité a komplexní, ale v podstatě jde o to, vyzkoušet si pár základních principů – Plánování, týmovou spolupráci, komunikaci se zákazníkem, reakci na změnu. A retrospektivu. Jednou z možných her zaměřených na prožitek ze Scrum procesu jsme navrhli s Petrem Olmerem stavbu železnice. Základem je postavit železniční spojení mezi městy USA a dovést zákazníka kam potřebuje/chce. Produkt backlogem je vyhlášen cíl spojit města A, B a C. Tým si zvolí ScrumMastera a hra může začít. Každý sprint si tým po diskuzi se zákazníkem naplánuje Sprint Backlog v závislosti na daných prioritách. Pak si každý člen vytáhne kartičky určující jeho rychlost, a případnou změnu celkových bodů. Tyto individuální rychlosti se sečtou a tým prezentuje, kolik železnice postavil. Cílem je mít funkční produkt a spokojeného zákazníka.

Potřebujete:

  • Mapu USA s před vyznačenou trasou – my jsme zvolili tuhle. Za jednu user story se považuje dokončení úseku z jednoho města do druhého (města jsou označena čísly). Stavba jednoho lomeného úseku trati odpovídá 4 bodům.
  • Lepítka na jednotlivé user story v backlogu.
  • Tabuli rozdělenou na tři části: Backlog | In Progress | Done.
  • Kartičky s rychlostí, které byl daný člen týmu schopen dosáhnout, které můžou vypadat třeba takto:

    • Proslýchá se, že nejpracovitější dělník dostane prémii, zkusím pracovat víc – 10
    • Odbory prosadily kratší pracovní týden – 5b
    • Je Den Železničářů, v poledne se jde do hospody – 4b
    • Včera pršelo, vypili jsme moc rumu – 3b

    Ale také třeba takto:

    • Měřiči špatně vykolíkovali trasu: +5b nová úloha: bourání špatně postaveného úseku – 3b
    • Vichřice povalila stoletý dub: +10b nová úloha: odstranění stromu – 0b

      • V tomto případě se do backlogu přidá nová úloha, která se musí z odpracovaných bodů dokončit jako první a pak je teprve možné pracovat dál na naplánovaných úlohách.

  • Větší hodiny měřící délku Sprintu, my jsme zvolili:

    • 5min – pre-planning & planning – tým na tabuli naplánuje user stories pro daný sprint
    • 5min – vyhodnocení & customer demo – každý člen týmu si vylosuje kartičku s rychlostí a podmínkami ve kterých daný sprint pracoval, Scrum Master je zodpovědný za zpracování výsledků a zorganizování customer dema.

    Nestihne-li tým všechny úkony včas (plán, vyhodnocení, customer demo, …), nejsou mu jinak hotové úseky uznány.

  • Zákazníka – toho budete pravděpodobně hrát Vy – který může:

    • Chtít vidět další města
    • Změnit svá přání

    Je už jen na týmu a jeho vyjednávacích a prezentačních schopnostech, aby zákazníka uspokojil, či mu vysvětlil, že daný požadavek na změnu nestihne.

Cílem, jak jsem psala nahoře je mít funkční produkt a spokojeného zákazníka. Hodnotí se tedy, jestli byl tým schopen dokončit úlohy v backlogu a jestli je zákazník spokojen s výsledkem.

Celkem jsme hráli na 6 Sprintů, tedy celá hra vyjde na hodinu. Před hrou budete potřebovat cca 15 minut na vysvětlení a cca 15 minut na organizaci týmu a vytvoření úvodního backlogu. Po hře cca 30 minut na prezentaci celkových výsledků jednotlivých týmů a retrospektivu.

Na závěr přikládám prezentaci ke hře. Jestli budete mít jakékoli dotazy, náměty pro zlepšení, nebo zkušenosti, dejte vědět.

Retrospektiva – kolečko

Jednou z nejdůležitějších agilních praktik je retrospektiva. Cílem je zapojit tým do rozhodování o procesu, nechat je vyjádřit svůj názor, ale hlavně poslouchat se navzájem a pochopit, že ne každý se dívá na věc stejně. Retrospektivou se učíme a uvědomujeme si, co jsme dělali dobře a co ne. Ideální frekvence je po každém sprintu, aby se problémy zbytečně neprohlubovaly a tým měl pravidelnou a častou možnost zhodnotit, jak sprint probíhal z pohledu každého člena.

Jak retrospektiva vypadá? Možností je několik, ale začneme tou nejjednodušší. Tou je takzvané kolečko kdy všichni členové týmu odpoví na dvě základní otázky:

  • Co se mi líbilo, co co jsme dělali dobře a chtěli bychom v tom pokračovat
  • Co se mi nelíbilo a chtěli bychom to změnit

Nezapomeňte, že retrospektiva je o pocitech, jak jsem to viděl já, co jsem si myslel, jak jsem se cítil. Pocit je osobní, neklade si nároky na to být universální pravdou.

V dobře fungujícím týmu se vám může lehce stát, že nikdo v týmu nemá pocit žádných problémů a že tým subjektivně funguje dobře. Potom se popsaný framework rozšiřuje o další oblast:

  • Co by se mohlo vylepšit nebo zefektivnit

Ideální tým ani proces neexistuje, vždy se dá něco najít, jen je to občas těžké si uvědomit.

Začnete-li s retrospektivou, tým začne přemýšlet o věcech jinak, jednotlivý členové budou mít pocit, že má smysl promluvit a zapojit se. Přestanou být pasivními členy čekajícími na úkoly. A jste zase o krůček blíže k vysněnému ‘self-organized‘ týmu.

Posílení týmu – ‘self-organized‘ tým

Jedním z často skloňovaných výrazů je ‘self-organized‘ tým. Týmy přecházející na agilní metody často začínají ranním Scrum meetingem, jako první zaváděnou praktikou. Jistě pomůže při sdílení informací a posílí týmovou spolupráci, ale nedá sám o sobě jednotlivým lidem pocit, že i na jejich názoru záleží, a že je tedy jen na nich, jak si vše zorganizují. K tomu, aby tým byl opravdu zapojen do procesů, je třeba dát všem prostor se k procesu vyjádřit a ovlivnit ho. Proto je důležité dělat retrospektivu. Dalo by se říci, že vlastně nemusíte ani vymýšlet žádný do detailu zpracovaný proces, stačí začít s retrospektivami a proces odpovídající vašemu prostředí vznikne za pomoci lidí v týmu sám. A jako všechno to, kde se sami podílíte na rozhodnutí, je i takto vzniklý proces stabilnější, robustnější a efektivnější.

Retrospektiva vás donutí zastavit se a podívat se co jste dělali dobře, a co špatně. A tedy dává prostor ke zlepšení, vytváří podmínky ke změnám, a posiluje proces učení se z toho, co se stalo. Měla by proto probíhat pravidelně, po každém Sprintu. Každý by měl dostat prostor vyjádřit své pocity, jak to vnímal on sám, co se mu líbilo a co by naopak změnil či vylepšil. Nastaví se tak týmu zrcadlo, kde je najednou vidět, co funguje dobře a co ne. A aby jako takové zrcadlo fungovalo, musí mít jednotliví členové stejnou možnost svoje pocity prezentovat. Aniž by je někdo hned opravoval, že nemají pravdu a že s nimi nesouhlasí. Jsou to přeci pocity konkrétního člověka, ne univerzální pravda. A vnímat věci jinak má každý právo.

Aby byla retrospektiva funkční, musí vždy, bez vyjímky, na identifikované problémy následovat akce, která se pokusí problém minimalizovat či odstranit. Řešením může být jak změna identifikovaného procesu, tak i vysvětlení proč takový je. Na spoustu problémů může tým již během retrospektivy pomocí brainstormingu navrhnout řešení, na složitější problémy si můžete vzít čas na rozmyšlenou. Ale něco by se mělo stát a při příští retrospektivě by se mělo vyhodnotit, jestli akce pomohla, či ne. Čím více zapojíte tým do navrhování řešení, tím rychleji se problémy spraví. Tým ví obvykle nejlépe sám, co mu chybí, co je dobré, a co ne.

Extreme Scrum přednáška na Agileee

První ročník konference Agile Eastern Europe 2009 v Kievě je za námi. Agileee měla dobrou atmosféru a spoustu velmi zajímavých lidí. Mám-li vybrat top 2 přednášející, určitě by to byli J.B.Rainsberger se svojí přednáškou “An Introduction to Agile Through the Theory of Constraints” a David Hussman s přednáškou “Agile Journeys: How Did We Get Here and Where are We Going?”. Budete-li mít někde možnost si je poslechnout, určitě to stojí za to.

Moje přednáška je ke shlédnutí níže. Pojednává o speciální case study kdy byl použit Scrum v extrámním prostředí kde se projekty počítají na hodiny. Řešením specifické situace bylo nasazení Scrum metody a půldenního sprintu. Výsledky byly velmi pozitivní.

Část case study byla také publikována na konferenci SoMeT, 8th International Conference on Software Methodologies, Tools and Techniques.

Scrum process under specific extremely short conditions

View more documents from agileee.

Dva druhy lidí…

Z pohledu managementu jsou jen dva druhy lidí. Jeden, který by se dal charakterizovat slovy ‘co neměřím, to neřídím‘, a pak ti, co se více než na nějaké striktní procesy a čísla spoléhají na svojí intuici a selský rozum. Skupiny jsou to zcela disjunktní, a přesto že spolu mluví, jen velmi těžko si opravdu rozumí. Žijí v odlišném světě. Někde tady se podle mého soudu nachází základní problém zavádění agilních metod řízení.

Např. Scrum je založený na týmové spolupráci, týmové zodpovědnosti, a týmovém rozhodování. Zkuste tedy vysvětlit klasickému managerovi ze staré školy, že zodpovědnost za projekt má tým. On přeci musí mít jednoho člověka. Tomu odpovědnost naloží a ostatní ignoruje. Další obtíž nastane, když se tým rozhodne něco změnit. Vše přeci musí být popsáno procesy a ty se nejenže nemění, ale musí se i dodržovat… Po čase skončíte tak, že děláte (Agilní) interface dovnitř týmu a (klasický procesní) interface svému managerovi. A to samozřejmě bude funkční jen z poloviny. Agilní kultura se tak nevytvoří. A je otázka, jestli to pak celé nebude na úrovni isolovaných praktik, jako když např. místo komplexního systému testování zavedete unit testy. To je sice samo o sobě super, produkt bude trochu lépe otestovaný, ale asi to nezaručí tu pravou kvalitu.

Jak tedy přesvědčit managery co nikdy nic jiného nezažili, že Agilní metody mohou fungovat dříve, než vás utlučou svými formálními performance measurementy? A jde to vůbec? Nebo takové metody a kultura funguje jen ve firmách s opravdovými leadery, co upřednostňují dlouhodobý cíl před krátkodobým ziskem? Na závěr, k těm procesům, si neodpustím otázku. Máte ve firmě ISO? A pomáhá vám nějak v tom být lepší, kvalitnější a úspěšnější?

Paradoxně mám pocit, že se všude mluví o tom, jak přesvědčit zákazníka. Pro většinu firem ale musí být daleko těžší přesvědčit svoje vlastní lidi. Myslím, že přesvědčit zákazníka je o mnoho snazší, než si získat podporu formalistů a striktně procesně založených lidí.

Zajímal by mě Váš názor a zkušenosti. Takže prosím o diskuzi, ať už tady veřejně, nebo emailem.

Zavádíme Agilní metody agilně

Jistě jste si už mnohokrát zkusili zavádět v praxi nějaké novinky. Obvyklý postup je začít prezentací, ukázat o čem nový způsob práce je, co jsou jeho výhody, jaká jsou očekávání. Začnete-li takto ‘po staru‘ prezentovat Agilní metody, pravděpodobně se dočkáte spousty připomínek, že metody jsou moc americké, ve vašem případě z nejrůznějších důvodů nevhodné, přinesou spousty overheadu a sníží efektivitu. Proto se mě osvědčilo zavádět Agilní metody ‘agilně‘, tedy po částech a takříkajíc plíživě.

Základ je nikomu v týmu neříkat, že od teď nastane změna a bude se pracovat jinak. Lidé obecně změnu nemají rádi. Naopak. Vše je při starém, jen zavedeme každý den krátký meeting. Začneme neformálně, nějakou historkou, statusem projektu (stejně si všichni stěžují, že chtějí vědět co se děje) a postupně se začneme ptát jednotlivých lidí na to, co dělali včera a budou dělat dnes… zní to povědomě? Asi ano. A máme Scrum či Stand-up meeting tak jak má být. Tým si pozvolna zvykne, a ani mu to nepřijde. Vcelku snadný začátek.

K tomu aby se opravdu začalo plánovat v bodech sice nějaké vysvětlování potřebujete, ale když už umíte pěkně Scrum meetingy, znáte status jednotlivých úloh a i to jak vám jdou od ruky, máte pro to informace, co potřebujete. Mě se osvědčilo koncept seznamu úloh (nemusíte mu hned říkat backlog) vysvětlit, vysvětlit že ohodnocení odpovídá náročnosti a že ho budeme dělat v bodech. Pak už stačí nechat odhadovat úlohy jednotlivé členy týmu, klidně v hodinách, ale toto ohodnocení hned převádět na body. Složitější celky odhadnete sami. Po čase, kdy budete body vysvětlovat na konkrétních úlohách lidé koncept vstřebají a budou ho umět sami používat.

Dalším krokem je vytvořit plán na nějaké iterace (sprinty), ze začátku ho uděláte vy, později jeho vytváření delegujete na tým. A rovnou jim můžete dát burndown na nástěnku. Když budete mít týmů víc a podpoříte soutěživost, o pozornost máte postaráno. Někde během tohoto procesu zavedete prezentace zákazníkovi (customer demo) a začnete se ho ptát na zpětnou vazbu a priority. A to už máme v podstatě celý Scrum proces, aniž by o tom někdo věděl. A když už vám to tak pěkně funguje, můžete metody pojmenovat a dopilovat jejich formu.

Hledáte-li rady jak začít s Agilními metodami, většinou začínají komplexní teorií, kterou stejně tým bez vyzkoušení nepochopí a hlavně všemi metodami najednou (neboť jinak by to přeci nebylo dost agilní, to by nebyl ten pravý Scrum proces). Výše zmíněný postup je jen alternativou, která vám umožní dělat změnu procesu, aniž by to bylo vnímáno jako změna procesu. Jsou to jen takové drobné novinky, takové malé vrtochy našeho projekt managera, to přejde, chvíli budeme chodit na meetingy a on se třeba unaví…

Workshop agilního řízení a metodiky SCRUM

Ráda bych Vás pozvala na workshop agilního řízení a metodiky SCRUM. Workshop pořádáme spolu s Petrem Olmerem, pod záštitou Sun Microsystems a Agilního konsorcia. Kurz je plánován pro začátečníky a mírně pokročilé projektové manažery, produktové manažery, technické ředitele, analytiky, informační architekty a další.

Program kurzu

  • 9:00 – 10:00 Úvod, co jsou agilní metody, proč zavádět Scrum proces, základní terminologie
  • 10:00 – 10:15 Coffee break
  • 10:15 – 11:30 Sprint cyklus, plánování, odhady, ohodnocení úloh, burndowns
  • 11 :30 – 11:45 Vysvětlení Scrum hry
  • 11:45 – 12:45 Přestávka na oběd
  • 12:45 – 13:45 Scrum hra
  • 13:45 – 14:45 Retrospektiva
  • 14:45 – 15:00 Coffee break
  • 15:00 – 16:00 Agilita a psychologie

Více informací na stránkách Agilního konsorcia.

Scrum v extrémních podmínkách

Vraťme se k otázce pro jak velký tým a v jakých podmínkách lze Scrum proces použít. Ráda bych se podělila o svou poslední zkušenost se zaváděním Scrum procesu v té nejminimálnější představitelné podobě. Jak si poradit s krátkými projekty v řádu několika dní a týmu o velikosti jednoho člověka? První intuitivní odpověď je, že na Scrum můžete zapomenout. Všechny projekty by vlastně byly hotovy v rámci jednoho Sprintu, a tedy by to asi nemělo moc smysl. Jak ale zařídit abychom vždy přesně věděli, kde jsme a mohli rychle reagovat na třeba i drobné zpoždění a problémy? Zvlášť když zpoždění jeden den už může být pro úspěch projektu kritické.

Řešení je nasnadě. Nic nám vlastně nebrání Scrum proces použít, jen se musí vhodně upravit délka Sprintu. Prvním úkolem bylo vytvoření Backlogu. Jednotlivé úlohy, ohodnoceny body, byly rozděleny na celky v řádu pár hodin. Délku Sprintu jsme nastavili na půl dne. V takto krátce nastaveném Sprint cyklu už se nic neschová. Žádný delší oběd, ranní káva, ani problém se špatným ohodnocením úloh. Nic. Ale na druhou stranu, alespoň máte informace o tom, že projekt zítra nebude, již dnes v poledne. A tedy můžete zareagovat. Vyžádat si pomoc kolegy, zavolat zákazníkovi a domluvit si pozdější dodání. Pořád lepší než volat zpětně že jste to zase nestihli.

Takže jak to vypadá v praxi. Každý pátek se udělá plán na následující týden. V kalendáři rezervace času na jednotlivé projekty. Pro všechny týmy (i když tým o jednom člověku moc týmem není). Každý půlden se potom updatují Burndowny jednotlivých projektů, a případně kalendář, abychom věděli, proč se plán změnil. Docela hodně drsné. Ale hlavně, funguje to naprosto skvěle. Vzhledem k rychlosti výroby produktu, je to ale asi jediná možnost. Scrum meeting asi stačí jednou denně, na prodiskutování progresu a plánu na následující den.

Ještě jedna věc. Přesunuli jsme Burndowny na GoogleDocs, na změnu máme nastavené automatické emaily a tak stačí jen sledovat na mailu co se děje.

GoogleDocs, Backlog a Burndown Graf

O tom k čemu využít Burndown graf už jsme psala v minulém příspěvku. Template pro Microsoft Excel je k dispozici také. Nicméně takový Excel se špatně sdílí mezi distribuovanými týmy. Jednou z možností je použití nějakého komplexního online systému, ale to s sebou obvykle nese další výdaje na licence a často i omezení Vašeho procesu.

Dobrým řešením je použít GoogleDocs. Tady je jako public příklad, jak by mohl Burndown vypadat (http://spreadsheets.google.com/ccc?key=p8oML5C9M–uwofmhl1npew).

První list obsahuje Produkt Backlog. Každý Sprint se zaloguje kolik bodů se udělalo, a kolik ještě zbývá.

Tyto hodnoty je následně nutné přenést do oranžově orámované části. Zbytek už se dopočítá automaticky.

Velocity Graf je prvním ze série grafů. Červená oblast zobrazuje počet bodů, které by tým měl stihnout za jeden dané Sprinty. Modrá křivka odpovídá aktuálním výsledkům.

Dalším grafem je tradiční Burndown Graf, který modře zobrazuje, kolik bodů ještě zbývá, oranžově kolik se již dokončilo a červeně případné změny bodového hodnocení (viz řádky 10, 11 v Backlogu).

Poslední graf zobrazuje Burndown z pohledu očekávaného dokončení projektu. Modrá křivka zobrazuje aktuální počet bodů, co zbývá dokončit, červená je potom projekcí ukončení projektu. Obecně se dá říct, že pokud je modrá a červená křivka uvnitř oranžové a zelené oblasti, očekávaný konec projektu je stále v rámci projekt bufferu a vše je v pořádku.

Reflection meeting

Reflection meeting je další důležitou součástí Agilních metod. Vychází se z toho, že je v praxi těžké nastavit procesy napoprvé a bez dobré zpětné vazby od lidí co se jimi mají řídit. Agilní metody proto pracují v cyklu. Vždy po několika cyklech je vhodné se zastavit, poodstoupit a podívat se jestli navržený proces funguje. Není Sprint moc dlouhý/krátký? Je vždy na jeho konci co prezentovat? Jak funguje proces plánování? Je týmům jasná hodnota bodu? Atd.

Reflection meeting by mel všechny takové otázky vzít v potaz a zhodnotit situaci. Měl by být pravidelný, každé 2-3 Sprinty. Ideální je, když takový reflection meeting vede někdo zvenku, kdo má dobré zkušenosti jako coach, rozumí Scrum procesu a Agilním metodám, ale není přímo navázán na vedení projektu. Projektový vedoucí může být na meetingu, ale měl by být více jako pozorovatel. Rozhodně by neměl přebírat iniciativu a vysvětlovat proč to tak je. Cílem je nastavit dostatečně otevřené a bezpečné prostředí pro identifikaci a řešení problémů.

Dejte si pozor, aby měl každý stejný prostor promluvit a vyjádřit se k danému tématu. Vyhraďte např. každému minutu času, a dbejte na dodržení časového limitu. Meeting by měl identifikovat problémy a navrhnout možnosti řešení, ale nemusí nutně dojít k rozhodnutí. To už můžete nechat na projektových vedoucích. Rozhodně ale musíte na identifikované problémy rychle reagovat. Týmy nesmí mít pocit, že problémy jenom zametáte pod koberec. Akce musí následovat rychle. Ať už je to změna procesu či vysvětlení současného stavu.