Tag: retrospektiva

Retrospektiva – Hvězda

Jak již jsem psala, retrospektiva je asi nejdůležitější praktikou agilních metod a nedílnou součástí Scrum procesu. Protože, aniž byste se učili a vylepšovali a upravovali Váš proces, nikdy nebudete dostatečně agilní, ale ani efektivní, kvalitní a úspěšní. Při retrospektivě si uvědomíte, co jste dělali dobře a co ne. Co je třeba změnit a co naopak dělat i příště.

Další možnost jak dělat retrospektivu je takzvaná hvězda. Když už Vám základní framework tzv. kolečka přijde moc nudný, nechte lidi napsat jejich pocity na lístečky a ty následně umístit do kategorií dle následujícího obrázku: Stop Doing, Less Of, Keep Doing, More Of, Start Doing.

Retrospektiva - hvězda

I taková jednoduchá klasifikace občerství retrospektivu. Donutí všechny jít více do detailu a opravdu se zamyslet nad tím, co bychom chtěli začít dělat, co naopak dělat nechceme vůbec, co omezíme, co posílíme a v čem budeme pokračovat.

Nezapomeňte, jsou to pocity jednotlivých lidí a jako k takovým by se k nim také mělo přistupovat. Nikdo si nečiní nárok na universální pravdu. Všichni mají stejné právo se vyjádřit. A jenom tím, že se naučíte si vzájemně naslouchat, se stanete efektivnějšími. Zmizí zbytečné problémy a nedorozumění. A práce Vás bude více bavit. Retrospektiva musí vést k akcím, pravidlům, změnám. Nenechte ji tedy jen tak rozplynout do ztracena.

Co mi přineslo WebExpo 2010 – část 2

Abych pokračovala v načatém popisu Agilní sekce WebExpa kterou jsem pořádala:

Hodně speakerů se zaměřovalo na proces učení, protože bez učení se nemůžete zlepšit, a nechcete-li se učit, nemá smysl dělat retrospektivu, být iterativní, v podstatě ani být agilní. Yves říkal, že na to, abyste byli v něčem opravdu dobří, potřebujete 10 000 hodin tréningu. Ani sportovci se nestanou hvězdami přes noc. Musí se učit a zkoušet to znovu a znovu. A retrospektiva je ideálním nástrojem na učení se.

Když máte stabilní tým, ve kterém vše funguje a retrospektiva začíná být nudná, vezměte na Vaši retrospektivu managera či externího zákazníka. Třeba zjistíte, že z jejich pohledu už to tak skvěle nefunguje, a že se stále máte co učit a v čem se zlepšovat.

Máte-li problém, že ne všichni se do retrospektivy zapojují, zařiďte, ať všichni musí promluvit během prvních 5minut retrospektivy. Bude pro mě pak snazší se zapojit.

Mějte respekt k těm, co tam nejsou, vždycky bude někdo chybět a příště to můžete být i Vy.

A poslední dobrá rada k retrospektivě, jedním z dobrých nápadů je říct něco dobrého o kolegovi. Může to být to snazší, než chválit sám sebe a přinese to retrospektivě nový rozměr.

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.