Dostali jste se do stavu, kdy jsou vaše retrospektivy jako “přes kopírák”? Přemýšlíte nad tím, jak je oživit a vdechnout tak týmu nový impuls? Pokud jste ještě nečetli náš článek Mistrovství v retrospektivách, určitě se do něj podívejte, naleznete v něm spoustu cenných tipů. Kromě tipů, jak dosáhnout pomyslného agilního ráje v retrospektivách, jsme pro vás sepsali pár dalších tipů, které mohou pomoci vytrhnout tým ze stereotypu a vrátit tak retrospektivám zapomenutý lesk. Vyzkoušejte netradiční formáty, zajímavé online nástroje nebo jen do vašich retrospektiv přidejte nový prvek.

Netradiční formáty retrospektiv

Hodně týmů se spokojí s klasickým formátem retrospektiv “+/-”. Jiný formát vám nezaručí automaticky úspěch, ale pomůže lidem podívat se na danou věc z jiného úhlu pohledu. Všechny uvedené formáty můžete praktikovat nejen s týmem v kanceláři, ale také online.

Top Gear

Znáte Cool zeď z pořadu Top Gear na které se hodnotí auta? Napadlo vás někdy v tomto duchu udělat retrospektivu? Vytvořte zeď přesně takovou, jako je na videu a požádejte váš tým, aby ji zaplnil čímkoliv, co považuje za důležité (firma, produkt, lidé, tým, procesy, …). Poté společně diskutujte, které věci byste chtěli posunout více doprava. Sloupec “Sub zero” je pomyslná nirvana, jakmile dosáhne kartička této úrovně, je natolik dobrá, že už na ní není co dále zlepšovat. Doporučujeme retrospektivu udělat znova třeba za čtvrt roku a uvidíte, co se změnilo.

Loď

Představte si, že máte jako tým za úkol nakreslit loď. Facilitátor vás požádá, abyste na obrázek k trupu lodi přikreslili velké plachty, kormidlo, kotvu a v neposlední řadě také útes před lodí. Poté dostanete za úkol napsat na lístečky vše, co pro vás bylo důležité za uplynulý sprint, ať už pozitivní nebo negativní. Jakmile máte napsáno, vezmete lístečky a lepíte je na ty části lodi, které nejlépe vystihují podstatu lístečku. Například “plachty nás pohání kupředu, a proto zde dávám automatické testy, protože nám výrazně pomáhají a vše urychlují” nebo “táhne nás ke dnu spousta byrokracie”, proto dávám ke kotvě.

LEGO

Pokud vás zajímá, jak se členové vašeho týmu dívají na právě skončený Sprint, chcete zároveň povzbudit kreativitu a udělat částečný teambuilding, zvolte právě Lego retrospektivu. Před tým položte spoustu různých lego kostiček a každý postaví cokoliv, co podle něj reprezentuje minulý sprint. Někdo postaví například spolu si povídající postavičky, někdo zase pokažené autíčko poukazující na problémy v týmu a kreativní jedinci mohou kostičkami například vizualizovat nepořádek v backlogu. Tento formát vám pomůže pochopit, jak jednotliví členové týmu vnímají týmovou spolupráci.

Futurospektiva

Čeká vás náročný projekt nebo iniciativa? Zkuste vzít retrospektivu z opačné strany a pohlédněte do budoucnosti. Otázky, na které je dobré se ptát v rámci této speciální retrospektivy, jsou například: 

• Přání – Co si přejeme, aby se nám v budoucnu splnilo?

• Obavy – Z čeho máme jako tým obavy?

• Rizika – Jaká vidíme rizika a jak je můžeme minimalizovat?

Díky této aktivitě pak bude celý tým lépe připraven na téměř cokoliv, co během projektu nastane.

Online nástroje

Pokud máte část týmu doma na home-office, můžete využít skvělé online nástroje. Zde je pár těch, které používáme velice rádi a můžete je vřele doporučit.

Jamboard

• Jednoduchý nástroj zdarma od Googlu, který funguje jako virtuální tabule. Můžete na ní kreslit, přidávat lepící papírky, mazat apod. – fantazii se meze nekladou. Jedinou výhodou a zároveň nevýhodou je jeho jednoduchost.

• https://jamboard.google.com

Miro

• Momentálně asi nejkomplexnější nástroj pro vzdálenou spolupráci – podporuje vše od designu meetingů typu Story mapping až po Kanban boardy, roadmapy, mindmapy a škálování agilního vývoje.

• https://miro.com

Ideaboardz

• Jednoduchá a neplacená verze tabule pro retrospektivy, která obsahuje již předdefinované šablony na některé formáty, nebo si také můžete vytvořit vlastní. Nástroj podporuje jednoduché hlasování, které oceníte při výběru tématu k diskusi.

• https://ideaboardz.com

Funretro

• Rozšířenější placená alternativa k Ideaboardz, která nabízí více předdefinovaných formátů, komentáře k jednotlivým poznámkám, limitování počtu hlasů, skrytí výsledků během hlasování pro objektivnější výsledek, jednoduchý export a mnoho dalších pohodlných možností pro co nejjednodušší facilitaci retrospektivy.

• https://funretro.io

Nový prvek

Říká se, že i na maličkostech záleží. Jestliže nemáte se svým týmem zrovna chuť na velkou změnu, podívejte se na pár tipů, které nestojí moc, ale mohou hodně pomoci.

• Časová osa Sprintu – vytvořte do kanceláře časovou osu, na kterou může každý zaznačit klíčový okamžik Sprintu spolu s kladnou nebo zápornou emocí. Díky tomu téma do retrospektivy nezapadne.

• Ad-hoc retrospektivy – nečekejte na to, až bude po 14-ti dnech velká retrospektiva, ale naopak dejte lidem z týmu možnost svolat ad-hoc retrospektivu a řešit téma ihned kdykoliv v průběhu dne. Z výsledku budete benefitovat okamžitě.

• Kartičky nálad – použijte je jako ice-breaker na začátku retrospektivy. Cílem je zjistit, jak se kdo z týmu právě cítí. Dají se koupit kartičky velryb s různými grimasami, které rozhodíte na zem, každý si jednu vybere a popíše proč si ji vybral a jak se cítí.

• Statistické okénko – vizualizujte na začátku týmu zajímavé statistiky. Můžete si ukázat trend vývoje počtu bugů, technického dluhu, úspěšnost plánování nebo třeba spokojenost zákazníka s vaším produktem.

• Pozitivní retrospektiva – na dnešním setkání nesmí zaznít nic negativního, pouze se chválíme a díváme se na to, co děláme buď jako jednotlivci nebo jako tým dobře.

• Retrospektiva na retrospektivu – vyhraďte si posledních 10 minut na to, abyste udělali retrospektivu právě skončené retrospektivy. Ujasníte si v týmu, v čem retrospektivy fungují a kde je prostor pro zlepšení.

Závěrem bychom vás chtěli podpořit v experimentování s retrospektivami. Není nic horšího, než když tým už půl roku jede pořád stejně, neustále se opakuje ten samý formát a setkání už dávno opustil život. Vyzkoušejte něco nového, ať to bude drobnost nebo velká věc – to nejhorší co se vám může stát je to, že se to nepovede. Alespoň budete vědět, kudy cesta nevede…

Zažili jste někdy situaci, kdy máte před sebou obrovskou věc a nevíte z které strany začít? Řešíte, jak uchopit rozpad nové funkcionality tak, abyste co nejdříve dodali zákazníkovi co největší hodnotu a až poté dělali na dalších částech? Právě pro vás může být velmi užitečná metoda User Story Mapping, která se používá pro rozpad velkých celků na menší. Připravili jsme pro vás proto praktický návod krok za krokem, který vás technikou provede.

O co se jedná?

• Vizualizace uživatelského toku v čase – vizualizuje akce, které dělá uživatel v systému, aby dosáhl (předem) definovaného cíle.

• Užitečný nástroj na tvorbu kostry Backlogu pro Tým nebo Squad.

• Výsledná mapa pomáhá týmu a Product Ownerovi s prioritizací a určením toho, co je pro zákazníka skutečně důležité.

• Prvním výstupem User Story Mappingu je množina User Stories, které dohromady tvoří MVP (Minimal Viable Product).

Jak metodu použít?

1. Vyberte zástupce různých rolí – Vývojář, Designér, Tester, Product Owner (ideálně max. 10 lidí).
2. Požádejte Product Ownera o sepsání krátkého popisu toho, co je potřeba zmapovat, ideálně ve formátu:
   1. CO? – produkt, nová funkcionalita, kterou chce přidat, nebo problém, který potřebuje vyřešit;
   2. PRO KOHO? – popisuje zákazníky produktu nebo uživatele, kteří budou danou funkcionalitu využívat. Pro každého takového uživatele explicitně popsat, co mu to přináší;
   3. PROČ? – popisuje důvod, proč se firma rozhodla danou funkcionalitu nebo produkt vytvořit. 
3. Vyhraďte si 2-3 hodiny času a prostor s velkou tabulí nebo zdí.
4. Začnete představením vstupu Product Ownera a pokračujte společnou definicí:
   1. Startovacího bodu – bod, ve kterém uživatel vstoupí do systému, začne svou interakci (např. Uživatel se přihlásí do webového rozhraní internetového bankingu);
   2. Cílového stavu – cílový stav, kdy je potřeba firmy/zákazníka naplněna (např. Uživatel provedl finanční transakci).
      
5. Společně ve skupině vytvořte tzv. Páteř (Backbone) Story Mapy tak, že pojmenujete větší aktivity, které uživatel musí v systému udělat, aby dosáhl cíle definovaného v minulém kroku. Aktivity vizualizujte na zdi/tabuli zleva doprava tak, jak jdou za sebou v čase.
6. Každou aktivitu rozpadněte na menší části – tzv. Uživatelské úkoly (User Tasks). Přemýšlejte nad:
   1. Alternativními způsoby, jak lze danou aktivitu v systému realizovat;
   2. Jaké okrajové případy mohou nastat (něco nebude fungovat, spadne server apod.)?
   3. Jak by k dané aktivitě přistupovali různí uživatelé systému?
   4. Detaily aktivity a různými vylepšeními;
7. Při tvoření se snažte vertikálně prioritizovat podle hodnoty a důležitosti daného zákaznického úkolu. 
8. Vyznačte na mapě první nejmenší řez zleva doprava, kterým je zákazník schopen dosáhnout definovaného cíle – vzniká MVP release (na obrázku znázorněn červenou čarou).
9. Pokračujte vyznačením dalších řezů, z nichž každý přidá další novou ucelenou funkcionalitu pro zákazníka. Platí pravidlo – 1 řez = 1 release. Při určování dalších řezů můžete zvažovat:
   1. Různé persony – můžete zacílit konkrétní inkrementy/release na konkrétní typy uživatelů (např. po doručení MVP se zaměřit na firemní zákazníky a na základě toho prioritizovat jednotlivé uživatelské úkoly);
   2. Přidání dalších klíčových možností a alternativ do produktu podle důležitosti nebo nejčastějšího způsobu využití.
10. Po vybudování User Story Mapy a vydefinování řezů můžete výsledek “překlopit” například do JIRA a máte tak vytvořený iniciální Backlog.
    1. Jeden řez reprezentuje ideálně jeden Epic. 

    2. Priorita v Backlogu je dána řezem shora dolů a pak po sloupcích zleva doprava (viz. čísla v pravém dolním rohu kartiček na obrázku).

Kdy není technika vhodná?

• Nový produkt nebo funkcionalita nevyžaduje žádné nebo pouze minimálni interakce uživatele v systému (např. technické změny na pozadí, refaktoring apod.).

• Nová funkcionalita je pouze malá změna v obrovském fungujícím systému (mapování stávajícího systému by zabralo hodně času).

• Chcete si pouze namapovat Stories, které už máte předem vymyšlené (lidé nebudou brát výsledek za svůj, protože je už vše dáno dopředu).

• Pokud nejste schopni svolat na jedno místo dostatek rozdílných rolí – můžete přijít o důležité nápady, perspektivy, otázky, poznatky (minimum je Product Owner, Vývojář, Tester a Designér).

Pokud byste si chtěli vyzkoušet techniku v praxi, neváhejte se nám ozvat, velmi rádi vás workshopem provedeme od začátku až do konce na konkrétním příkladu z vaší praxe.

Jeden z principů Agilního manifesta říká: ,,Tým se pravidelně zamýšlí nad tím, jak se stát efektivnějším a následně koriguje a přizpůsobuje své chování a zvyklosti.“ Jedním z klíčových nástrojů pro naplnění tohoto bodu jsou nepochybně retrospektivy.

Mnoho týmů je s železnou pravidelností praktikuje, vkládá do nich nemalé usílí, ale očekávaný výsledek se stále ne a ne dostavit. Častou příčinou může být to, že v nich chybí ingredience, které způsobí, že budou mít tu správnou šťávu.

Přinášíme vám proto 11 praktických tipů, které pomohou vaše retrospektivy posunout ještě dále – k mistrovství.

1. Přesnost je výsadou králů

Čekáte 15 minut po začátku, než si všichni uvaří kafe a sejdou se v místnosti? Začínejte vždy na čas a případným opozdilcům neshrnujte, co se probralo do jejich příchodu. Uvidíte, že se časem naučí chodit včas, aby o nic zajímavého nepřišli. To mimochodem platí i u ostatních meetingů. Facilitátor by měl vždy dorazit o pár minut dříve, aby si stihl připravit místnost a vše nezbytné pro hladký průběh retrospektivy.

2. Vyhnívající akční kroky

Generujete akční kroky, ale nikdo je neplní? Ještě důležitější, než dělat retrospektivy, je systematická práce s akčními kroky. Každá retrospektiva musí začínat tím, že zkontrolujeme akční kroky z minula a pobavíme se o tom, v jakém jsou stavu. Když to uděláte poprvé, možná se stane hlavním tématem retrospektivy téma, proč jako tým neplníme akční kroky a co je potřeba změnit. I toto je v pořádku. Dobrou praxí, jak mít úkoly neustále na očích, je jejich přepsání na fyzickou tabuli v kanceláři nebo se domluvit s týmem a procházet je alespoň dvakrát do týdne na konci Daily stand-upu. 

3. Děláme pořád stejný formát

Lidé vědí, co čekat, přicházejí s již napsanými lístečky a generujete pořád stejná témata? Zkuste něco nového, nabídněte týmu jiný úhel pohledu na jejich práci a přineste jako facilitátor něco zábavnějšího než + a -. Dobrým odrazovým můstkem je Retromat, kde si můžete generovat náhodný formát. Nebo si zkuste vymyslet úplně vlastní formát. Uvidíte, že to není nic složitého. 

4. Řešíme stále jen problémy

Už jste zkusili udělat pouze pozitivní retrospektivu? Určitě neděláte vše špatně a je spousta věcí, které jako tým děláte dobře a můžete se za ně poplácat po zádech. Zkuste pro jedenkrát zakázat hovořit o problémech a uvidíte efekt. Máme velice rádi tzv. KUDOS, kdy můžete ocenit kohokoliv z týmu a poděkovat mu za pomoc nebo něco neobyčejného, co vykonal v tomto sprintu.

5. Chceme vyřešit všechna témata

Když už jsme si dali práci s generováním témat, tak máme pocit, že je nemůžeme nechat nevyřešené. Je naprosto v pořádku, když po prioritizaci proberete pouze jedno téma s největším počtem hlasů, kvalitně a do hloubky. Pokud jsou ostatní věci důležité, objeví se hned na další retrospektivě.

6. Tým ukazuje na všechny okolo

Retrospektiva je primárně záležitostí týmu, i když se samozřejmě mohou objevit i témata, ke kterým potřebuje někoho dalšího. Měli bychom však pokaždé začínat u sebe a svého týmu, neboť to jsou věci, na které máme stoprocentní vliv a můžeme je okamžitě změnit. Jakmile máme uklizeno “doma”, jdeme za hranice týmu. Dobrý facilitátor toto dokáže týmům zvědomit a vrátit je zpět k myšlenkám, co mohou oni sami změnit.

7. Musíme nutně využít všechen čas

Dobrá zpráva pro vás – rozhodně nemusíte. Pokud není dnes co k řešení a nebo jsme již vše probrali, skončete klidně po 20ti minutách. To nejhorší, co můžete udělat je, že budete neustále zkoušet generovat na sílu další témata a snažit se vyplnit čas. Využijte ho například tím, že si dáte jako tým společné kafe nebo procházku na čerstvém vzduchu – bude v tom rozhodně větší hodnota. Pokud se však tato situace opakuje už potřetí, je na čase zkusit jiný formát, protože už tým mohl spadnout do stereotypu a “zlenivět”.

8. Hledání svatého grálu

Již několik retrospektiv se vrací to samé téma, diskutujeme jej neustále dokola a bez jakéhokoliv výsledku. Zkuste na místo hledání ideálu udělat už konečně aspoň malý krůček vpřed, malý experiment, který vás posune vpřed. Možná nebude ideální, možná bude úplně mimo, ale pořád lepší něco vyzkoušet, než to půl roku do posledního detailu pouze promýšlet.

9. Prázdné akční kroky

Dbejte vždy na to, aby všechny akční kroky, které vypadnou z vaší retrospektivy, byly přiřazeny na konkrétního člověka, bylo specifikováno, co konkrétně se má udělat a do kdy má být úkol splněn. Můžete využít například techniku SMART. Každá retrospektiva by měla končit alespoň jedním akčním krokem. Scrum Guide dokonce hovoří o tom, že by alespoň jeden akční krok měl být naplánován do dalšího sprintu.

10. Všechny úkoly jsou na Scrum Masterovi (SM)

Typickou situací je, že je SM zodpovědný za proces a nasazení Scrumu, a proto tým nabyl dojmu, že je také zodpovědný za všechny úkoly z retrospektivy. V tomto případě může SM nabídnout týmu, že úkol udělá s některým členem týmu v páru nebo si vezme na sebe maximálně jeden úkol a zbytek si musí rozebrat tým.

11. Retrospektiva je monotónní

Zkuste naplánovat retrospektivu na nějakém netradičním místě. Někdy postačí meetingovka se sedacími vaky, která vykouzlí neformální atmosféru nebo zajděte ven do parku. Alternativou může být posezení u (nealko) pivka v hospůdce, kterou má tým nejraději. Nebojte se popustit uzdu své fantazii a experimentovat.

Pokud Vás některý z tipů zaujal, neváhejte ho vyzkoušet a dejte nám vědět, jak tento experiment zafungoval ve vašem týmu.

Henrik Kniberg dal svého času dohromady seznam Scrum praktik. Čas od času jej při zavádění Scrumu v týmech s úspěchem používáme a tak jsme se rozhodli jej přeložit do češtiny a nasdílet s vámi. Seznam pro vás může být dobrou inspirací pro další rozvoj týmů nebo může posloužit jako rychlé barometr zavádění Scrumu.

Český překlad můžete stáhnout zde.

Jak Scrum checklist použít?

Tip #1:

Zkuste tento seznam použít v rámci pravidelných retrospektiv v týmech, které zavádějí Scrum. Vyberte si ze se znamu několik praktik, které chcete v týmu zavést (10-12 max.) a nechte tým během retrospektivy hlasovat, nakolik si myslí, že tato praktika již v týmu funguje (doporučujeme použít techniku hlasování s pomocí karet s čísly jako při Planning Pokeru, aby se členové týmu vzájemně neovlivňovali).

Pokud je průměrná hodnota pro danou praktiku nízká, pak nechte tým diskutovat o tom, jaké akce mohou napomoci jejímu zavedení.

Pokud se tým neshoduje v hlasování (velký rozptyl odpovědí), pak nechte členy týmu prodiskutovat proč hlasovali rozdílně.

Pokud chcete se zavedením pravidelného sebehodnocení týmu pomoct, pak nás neváhejte kontaktovat.

Tip #2:

Převeďte si tento seznam do Google Forms pro snažší sběr vstupů formou vyplnění členy týmu před retrospektivou.

Překlad originálního textu od Henrika Kniberga

Následující řádky jsou překladem originálního textu od Henrika Kniberga uvedeného na této adrese.

Pro koho je tento seznam a k čemu slouží?

Seznam Scrum praktik je jednoduchý nástroj, který vám pomůže začít se Scrumem nebo vyhodnotit vaši implementaci Scrumu.

Vezměte prosím na vědomí, že toto nejsou pravidla, pouze doporučení. Dvoučlenný tým se třeba může rozhodnout vynechat denní Scrum setkání, protože stejně celý den programují v páru a nepotřebují další synchronizační schůzku. Prima. Záměrně se rozhodli vynechat jednu ze Scrum praktik, nicméně zajistili, že je účel této praktiky zajištěn jiným způsobem. A to je to podstatné!

Pokud pracujete podle Scrumu, může pro vás být zajímavé použít tento seznam během týmové retrospektivy. Jako nástroj pro diskuzi, nikoli hodnocení.

Jak to mám použít?

Jarda: „Přinesl jsem na dnešní retrospektivu krátký zajímavý seznam Scrum praktik. Je na něm něco, co neděláme?”

Katka: „Tak se na to podívejme. Hm, rozhodně nám chybí Definition of Done a taky nesledujeme Velocity.”

Jarda: „OK, ‘Definition of Done’ je uvedena v části „Základy Scrumu“, takže vypadá důležitě! Velocity je v části ‘Doporučené, ale ne vždy nutné’ takže s tou počkejme a začněme tím nejdůležitějším.

Katka: ”Hele, taky nám chybí ‘Doručujeme fungující otestovaný software co 4 týdny nebo častěji’. To je uvedeno dokonce v sekci ‘To nejpodstatnější’!
A dává to smysl, protože marketing si na to pořád stěžuje!”

Jarda: „Možná by nám koncept ‘Definition of Done’ mohl pomoci brát si do sprintu menší celky a doručovat častěji?“

Katka: „Dobrý nápad, pojďme to zkusit.”

Jak to nepoužívat!

Velký šéf: „Dobře, týme, je čas podívat se, jak následujete Scrum. Vyplňte prosím tento dotazník.”

Jarda: „Šéfe, jsem rád, že můžu říct, že děláme všechno ze seznamu. No, snad jen kromě Sprint burndown charts.”

Velký šéf: „Jste špatný tým! Tady se jasně píše, že máte dělat… ty… sprint burning věci! Chci je vidět!”

Katka: „Ale my máme dvoutýdenní sprinty a téměř vždy dodáme, co slíbíme a zákazníci jsou spokojeni. Sprint burndown charts by nám teď nijak nepomohly.”

Velký šéf: „Ale tady se jasně píše, že je máte mít, tak ať už se to neopakuje, nebo zavolám Scrum policii!”

Je tento seznam oficiální?

Není. Tento seznam odráží můj osobní subjektivní názor na to, co je ve Scrumu podstatné. Už roky pomáhám firmám začít se Scrumem a potkal jsem stovky uživatelů Scrumu, trenérů a koučů; a zjistil jsem, že takovýto seznam může být užitečný, když se správně použije.