Přečtěte si co je nového v agilním světě, která témata jsou pro mě zajímavá.
Tahle retrospektiva se snaží podívat se na naše fungování přes pocity. Členové týmu popisují co je naštvalo, co je jim líto, a co je naopak super. Stejně jako v předchozích formátech můžete použít lístečky nebo jen nechat každého mluvit.
Výhody:
Nevýhoda:
Tip:
“Tři malá prasátka“ je pohádka o prasátkách co šla na zkušenou. Když došla na palouček, rozhodla se, že si postaví domečky. První prasátko bylo líné a postavilo si domeček ze slámy, aby si rychle mohlo hrát. Druhé sice věnovalo stavbě domečku trochu více energie a rychle postavilo domeček z klacků a běželo si hrát. Třetí pracovalo pilně celý den, a postavilo si domeček z cihel. Příští den šel kolem vlk, přes slámu ucítil prasátko a už se těšil, že bude večeře. První domeček rozfoukal, prasátko se jen taktak stihlo schovat to domečku z hlíny, když tu vlk klacky jednou ranou rozbořil jen taktak že prasátka utekla do domečku z cihel. Když ho vlk nebyl schopen rozbořit, rozhodl se, že do něj vleze komínem. Na to ale prasátka byla připravená, zatopila pod kotlem a vlk spadl do hrnce s vařící vodou…
Tato retrospektiva používá příběh jako metaforu a nechá tým přirovnat jejich systém a fungování k domečku ze slámy, klacků a cihel.
Výhody:
Příprava:
Tip:
Když už vás klasické formáty retrospektivy nudí, zkuste něco hravějšího. Asi nejznámější je metafora lodi plující na moři, kde vítr do plachet znázorňuje to, co nám pomáhá, kotvy to co nás brzdí. A kreativitě se meze nekladou, takže můžete přidat skalnatý útes jako problémy, žraloky jako akutní rizika, sluníčko jako úspěch,… a tak bych mohla pokračovat.
Výhody:
Příprava:
Tip:
Dalším oblíbeným formátem retrospektivy je takzvaná hvězda, kde klasický formát dvou otázek rozšíříte na pět segmentů a necháte tým se na daný Sprint podívat z různých úhlů – co bychom měli začít dělat, co dělat více, v čem chceme pokračovat, co dělat méně, co přestat dělat. Tým své podněty píše na lístečky a přiřazuje je daným segmentům.
Výhody:
Příprava:
Tip:
Tento formát retrospektivy je takový základ, kterým většina ScrumMasterů začíná. Každý člen týmu postupně řekne, co se mu líbí a mělo by se v tom pokračovat, a co se mu nelíbí, a bylo by potřeba změnit.
Výhody:
Nevýhody:
Tip:
Před tím, než představím top 10 formátů pro retrospektivu si pojďme zopakovat co že to taková retrospektiva je. Takže retrospektiva je takové pravidelné ohlédnutí se za minulým obdobím, většinou tak týden, dva. Pro ty z vás, co děláte Scrum je to každý Sprint. Pro ostatní agilní týmy by retrospektiva měla být pravidelná a častá. Tedy jednou za půl roku to nestačí. Účastní se jí celý tým, a na konci by měly být konkrétní akční kroky, které se tým zaváže udělat, tedy “Co uděláme příště jinak, aby se nám tohle už nestalo”. Retrospektiva, která na konci nedefinuje žádné zlepšení není retrospektiva, ale pouhý pláč nad rozlitým mlékem, a to nikdy k ničemu není. Stejně tak Retrospektiva, která se snaží dát úkol někomu mimo tým, se míjí účinkem. I když je identifikovaný problém někde jinde, tým se zamýšlí nad tím “Co můžeme udělat MY, abychom danou situaci změnili/zlepšili/ovlivnili”.
Retrospektivy se účastní celý tým, tedy včetně Product Ownera. ScrumMaster retrospektivu facilituje, tedy vybírá formát diskuse a pomáhá týmu hledat příčiny problémů a přijít se zlepšeními.
Retrospektiva má obvykle několik fází.
Na závěr je dobré shrnout co si tým vybral a zároveň můžete retrospektivu zakončit zase nějakým zábavným energizérem – třeba porovnat, jak se počasí, které členové týmu sdíleli na začátku, změnilo.
A kdyby vás to celé zajímalo ve formě videa, tady je přednáška, kterou jsem na téma retrospektivy měla na několika konferencích.
V dalších příspěvcích se podíváme na nejčastější formáty retrospektivy…
Když jsem před 10 lety začala pořádat agilní konferenci, tak jsem rozhodně nečekala, že to vydržíme 10 let. A vlastně ani že se nám podaří přivést tak zajímavé speakery do Prahy a vytvořit konferenci, která to z malé lokální české konference dotáhne na jednu z nejlepších konferencí v Evropě.
Konference byla od začátku celá v angličtině a cílem bylo sem přivést zajímavé lidi z celého světa, abyste se mohli podívat jak agile vypadá jinde, jak probíhají transformace, jak pracují agilní koučové, ScrumMasteři a Product Owneři ve firmách, které jsou na své agilní cestě trochu dál a které s agilem začínaly řekněme třeba v roce 2000.
Agile Prague má dva paralelní tracky. Máme většinou krátké 30 minutové přednášky, kde klademe důraz na praktickou implementaci a na příběhy z reálného světa. Každý den máme také openspace, kde si můžete popovídat s účastníky o různých situacích a jít více do hloubky témat, která byla na konferenci prezentovaná. Tématem letošní konference je „Sustainable Agility“.
Když mám jen namátkou vybrat něco z programu:
Alexey Krivitsky a Roland Flemm vám pomůžou „Zlepšit výsledky transformace v korporátních organizacích pomocí adaptivity“.
Boris Glogger se s námi podělí o své zkušenosti v přednášce „Udělejme to znovu – role agilního konzultanta pro udržitelný svět“.
Evan Leybourn se s námi podívá na to, co znamená vybudovat organizace připravené na cokoliv, co přinese budoucnost. Tedy jak vstřebat business agility.
Pat Guariglia bude mluvit o obavách ze změny. Každá změna je těžká. A agilní transformace mění styl myšlení a celkově přístup k věcem. A to nikdy není jednoduché.
Richard Cheng a Karim Harbott zakončí konferenci přednáškou na téma “Co je business agility a proč je důležitá”.
Agile Prague proběhne letos v pondělí a úterý 19.-20. září a je to akce, na které by žádný agilní nadšenec neměl chybět. Je to akce, na které by neměl chybět nikdo, kdo právě prochází agilní transformací. Je to akce, která dává dohromady současnou agilní scénu. Budeme se těšit že se tam společně uvidíme.
Jedna z takových častých otázek je, jak na Performance review ScrumMasterů. Já si myslím, že to je vlastně od samého základu špatná otázka. Agilní organizace totiž od takzvaných performance review upouští a nahrazují je tzv. peer review, tedy vlastně otevřenou zpětnou vazbu od kolegů. Když se bavíme o self-organized a self-managed týmech, role managerů v celkovém fungování organizací se umenšuje a přechází na týmy. Ale to je asi na jiný článek. Cílem ScrumMasterů není týmu říct jak mají pracovat, nastavit iniciální proces a pak ho jen udržovat, což by šlo měřit a dát do cílů docela dobře, ale cílem ScrumMastera je neustále challengovat to jak pracují, pomáhat jim se zlepšovat, měnit a adaptovat na nové podněty a změny. To se ale špatně měří a tedy i hodnotí. Takže na co se máme zaměřit?
Jak tedy poznáme, že ScrumMaster funguje dobře? Často tak, že ho tým nepotřebuje a ScrumMaster má tak čas pomáhat organizaci na její agilní cestě. Umět postavit dobře fungujícího samoorganizovaný tým je totiž jenom začátek. Jeden agilní tým toho zas až tak moc nezmění. Abychom si rozuměli, jeden dobře fungující agilní tým má potenciál změnit životy jeho členů tak, že budou mít radost z dobře vykonané práce, budu mít dobrý pocit, že něco smysluplného vytvořili. Budou spokojeni a motivovaní a to je něco co stojí za trochu práce a energie. Dobře fungující tým bude mít také dobrý výsledek, budou dodávat hodnotu, mít spokojenější zákazníky. A to taky stojí za trochu práce a energie. Ale to je jen začátek fungování ScrumMastera v rámci #ScrumMasterWay modelu – Můj tým, kde je zajímavé se dívat, jak se tým zlepšuje, začíná si věci řešit sám a čím dál tím méně spoléhá na ScrumMastera. Jinými slovy, jestli je self-organized, cross-functional, a v krátkých cyklech dodává hodnotu zákazníkovi. Je dobré si při tom uvědomit, že ScrumMaster rozhodně nemá na starosti updatovat žádné nástroje (Jira, …), ani reportovat status produktu (velocity, story points, …), ani řídit a organizovat ceremonie (tedy eventy).
Většina organizací ale nemá tak malé produkty, aby je stačilo dodávat jedním týmem a potřebuje spolupráci více týmů, aby dodalo reálnou hodnotu zákazníkům. Určitě musí jednotlivé týmy fungovat dobře, aby měly dobrý výsledek, ale to je jen začátek. Je vhodné ho neodbýt, protože když nepostavíte dobře fungující self-organized, ale hlavně cross-functional týmy, tak se většinou jejich spolupráce stává noční můrou a nefunguje ať děláte co děláte.
K tomu, aby jednotlivé týmy spolu dobře fungovaly, potřebujete ještě zajistit, že i spolupráce mezi těmi týmy funguje dobře, tedy že se nezastaví na úrovni jednoho týmu, ale že se společně zlepšují, posouvají, hledají nové cesty a adaptují. Takže ScrumMaster, který nastavil fungování na úrovní jednoho týmu, si vlastně uvolnil ruce pro práci na větším celku organizace a jeho cílem je nyní pomáhat více týmům se samoorganizovat, a najít si lepší cestu jak budou společně fungovat a dodávat produkty. Tedy mluvíme o fungování ScrumMastera v rámci #ScrumMasterWay modelu – Vztahy, kde cílem ScrumMastera je podpořit spolupráci a samoorganizovanost tohoto většího ekosystému složeného z více spolupracujících týmů. Díváme se na to, jak se společně zlepšují, adaptují, přebírají zodpovědnost a vlastnictví. Tedy stávají se samoorganizovanými. Stejně jako v předchozím bodě je dobré si uvědomit, že ScrumMaster není jejich asistent, který má řešit závislosti mezi týmy (třeba na Scrum of Scrums, … ), ani dodávku produktu.
No jak asi tušíte, ten největší impact dosáhnete, když se posunete na úroveň organizace jako celku a pomůžete celé organizaci se zeštíhlit, descalovat, a pracovat jako spolupracující síť samo organizovaných týmů. Tedy mluvíme o fungování ScrumMastera v rámci #ScrumMasterWay modelu – Celý Systém, kde cílem ScrumMastera je pomoci organizaci změnit kulturu, leadership styl, a celkové fungování. V jednoduchosti aplikovat business agility. A asi nemusím říkat, že to není o aplikaci žádných frameworků.
Abych se obloukem vrátila k původní otázce, tedy jak na hodnocení ScrumMastera. Prvním bodem je identifikace, na které úrovni #ScrumMasterWay modelu se ScrumMaster primárně pohybuje. Následně se zaměřte na to, jak pomáhá týmům a organizaci převzít zodpovědnost za samo(organizaci), jestli #ScrumMasterWay modelem roste od úrovně Můj tým, přes Vztahy, až po Celý systém, a jestli se zaměřuje na neustálé hledání lepší cesty.
ScrumMaster není asistent, procesní policie ani maminka. Je to kouč a leader který dokáže organizaci změnit. Ale o tom zase příště.
Jak se pozná opravdový Scrum od toho co je implementovaný jen naoko? Tak úplně první co slyšíte je výraz ‘ceremonie’. Řeknete si, no dobře, oni jen nevědí jak se to jmenuje, ale to nic neznamená. Jenže právě terminologie často poukazuje na hlubší nepochopení. V devadesáti procentech případů, když slyšíte termín ceremonie, tak jsou to zbytečné nesmyslné meetingy, které se dělají jen proto, že je někdo nakázal – ať už ScrumMaster nebo Scrum jako takový – tedy ve Scrumu to tak musí být. Ostatně když se podíváte na definici, dozvíte se něco o okázalém postupu podle předpisů. Takové ceremonie jsou nejen k ničemu, ale otravují prostředí, žerou energii a hlavně, vytváří obecnou nechuť ke Agilu, Scrumu a vůbec.
Když Scrum aplikujete správně, víte že to jsou eventy, tedy něco, co se děje, protože pro to existuje potřeba. Neříkáte tomu ani meetingy (ty jsou povětšinou nudné a nutné) ale je to takový happening. Mohli byste říct že je přeci jedno jak to nazýváte, a na jednu stranu je, ale na druhou název vždy ukazuje část vnímání. Dejte eventům smysl, najděte znovu jejich hodnotu a nikdo si na ně nebude stěžovat.
K tomu je ale několik pre-requisit. Za prvé, Scrum není proces jak micromanagovat (ani řídit) jednotlivce. Je postavený na spolupráci cross-functional týmu. A to bohužel ve většině organizací kde mají ceremonie chybí. Tedy abych byla specifická, když se na ně podíváte blíž, nejsou tým, tedy nespolupracují, nejsou cross-functional, tedy nedodávají hodnotu, jednotlivci pracují každý na svém úkolu, a mají rozdělené role. Narazíte tak na frontendisty, backenddisty, experty na systém X, na který nikdo jiný nesmí sáhnout (rozuměj máme to v kontraktu), a také na spoustu dependencí. A také na velice složitý proces v Jiře, a občas i několikastránkový diagram, kdo co dělá. Ne, opravdu Scrum není proces na zpracovávání ticketů. Ale to by vyžadovalo razantní změnu myšlení.
Klíčem opravdového Scrumu je tým, který v krátkých iteracích dodává hodnotu zákazníkům, získává zpětnou vazbu pomocí které se mění a iteruje produkt a své fungování. Scrum neoptimalizuje na rychlost, ale na řešení komplexních problémů, kde možností je mnoho a dopředu úplně přesně nevíme jaký směr zvolit. Je flexibilní ke změnám a dokáže se rychle adaptovat.
Takže jak od takového technického Scrumu naoko k tomu opravdovému?
A to je vlastně všechno. Není to složité, ale spousta organizací se takové změně brání. Agile přináší velkou změnu fungování. A taková změna je vždy těžká.
Svět se změnil. Může se nám to líbit nebo nemusí, ale v principu nám asi nezbude nic jiného než se té změně přizpůsobit. Spousta firem dneska mluví o tom, že se nebude vracet do kanceláří a nechá z větší či menší části virtuální fungování. A spoustě zaměstnanců se zpět do kanceláří ani nechce. Může tedy agilní tým fungovat ve virtuálním světě? No tak co by nemohl. Virtuálních týmu fungovala spousta i dříve, takže tomu vlastně vůbec nic nebrání. To jediné co je virtuálním světě horší, je udržovat dobré vztahy mezi lidmi. Spolupráce totiž nevzniká jenom tím, že někomu řekneme, že jsou tým, nebo že jim dáme nástroje, aby mohli spolupracovat. Je to hodně o důvěře mezi lidmi, je to o schopnosti komunikovat, být ochotni otevřeně řešit konflikty. A to se na dálku nedělá úplně dobře. Samozřejmě nástroje jako Zoom, kde se vidíte navzájem a můžete spolu mluvit jako byste seděli v jedné kanceláři, můžete se přesunout s libovolnou diskuzí do vedlejšího virtuálního prostoru stejně jako jste to dělali, když jste byli v officu, spolupráci pomáhají. Problém je, že čím déle budou týmy fungovat pouze ve virtuálním prostoru, tím méně se budou znát a to nemluvím jenom o těch, co nastoupili již za virtuálního světa, ale funguje tam takzvané sejde z očí, sejde z mysli. Přestanou chodit spolu na oběd, nezajdou občas na pivo, nebudou mít prostor si jen tak popovídat jako kolegové. A tak jak půjde čas, bude stále těžší a těžší otevírat složitá témata, řešit konflikty a říkat si věci tak jak jsou. Můžete namítnout, že ve virtuálním světě si můžete dát spolu kafe, drink, oběd. Ale asi budete souhlasit s tím, že to není ono. V podstatě by se dalo říct, že dnešní virtuální týmy jedou na dluh. A dříve či později je to doběhne. A to nemluvíme o tom, že by to nešlo. Šlo. Ale znamenalo by to proaktivně vztahy budovat.
Stejně jako v klasickém světě, i ve virtuálním světě máte v podstatě na výběr dvě možnosti. Buď pracovat jako jednotlivci, kteří si v nějaké podobě rozdají, nebo dostanou úkoly a pak na nich samostatně pracují. To ale nemá s týmovou spoluprací nic společného a je to čistě práce jednotlivců. Druhou možností je postavit dobře fungující silný tým, ale takový tým aby fungoval spolu, musí aktivně a intenzivně spolupracovat. Takové týmy měly často postavenou online session třeba na Zoomu nebo Google Hangoutu, kde spolupracovali v rámci celého dne, mluvili spolu, řešili věci dohromady, povídali si. A viděli se. A budovali tak vzájemnou důvěru, porozumění a vazby. Dnešní týmy často vizuál podceňují, říkají my si zavoláme, my si napíšeme, pošleme si message po Slacku. A nemám nic proti Slacku, nic proti telefonu, nic proti emailu. Všechno jsou to dobré nástroje pro komunikaci, ale spolupráci nenahradí.
Takže jak taková spolupráce ve virtuálním světě vypadá? Ráno když takzvaně přijdete do práce se připojíte na online video call (Zoom, Google Hangout, … ) který běží celý den, takže to není žádný status meeting a začnete pracovat. S tím jak se začnou připojovat kolegové, je to jako kdyby chodili do práce a vstupovali do kanceláře. Řeknete si ahoj, popovídáte si, zeptáte se co je nového a začnete postupně pracovat. Během dne spolu mluvíte a pomáháte si. Dnešní nástroje standardně umožňují spolupráci více lidí na jedné věci, takže to není problém. Místo tabule na stěně a papírových lístečků můžete používat třeba Mural, Miro, nebo Google Jambord. Jako doplněk můžete použít Slack pro asynchronní komunikaci, ale hlavním komunikačním nástrojem je vždy již zmíněná videokonference.
Většina týmů ale narazí na to, že nemá dostatečně silnou motivací pro spolupráci, připadá jim, že vlastně spolupracovat nepotřebují. Že stačí, když pracují jako jednotlivci a jednou denně se syncnou. A tak často upřednostní vlastní pohodlí, tedy zůstat doma a na žádný call se nepřipojovat, před intenzivní spoluprací a komunikací s kolegy. Důvody pro to můžou být dva. Jedním z nich je již zmíněná pohodlnost a takový nezvyk být pořád na kameře, přeci jen je to pořád ještě nové. Druhým je pak většinou to, že nemají dostatečně silný společný cíl a tak jim připadá, že kolegy pro řešení svých vlastních úloh vlastně ani nepotřebují. A jsme zpět v individuální práci. Zdání ale často klame. Problémy, které většina firem v dnešní době řeší jsou komplexní a s komplexitou si poradí lépe týmy, než samostatně pracující jednotlivci. Když ono ale postavit dobře fungující tým je práce, která trvá a stojí spousty energie. Jako vždy máte samozřejmě na výběr pracovat jako jednotlivci, nebo investovat do formování týmu a využít jeho výhody. Něco mezi většinou nefunguje a bere si nevýhody z obojího a bohužel právě tam spousta týmů končí. Nevyvinou dostatečnou energii pro formování týmu, ale snaží se předstírat že tým jsou a nutí jednotlivce do týmových meetingů, které ale pro práci samostatně pracujících lidí nedávají smysl a přináší jen zbytečný overhead. Není to o meetingách, ale o silném společném cíli.
Na závěr, čím jednodušší nástroje, tím lepší. Nenechte se chytit do pasti nových nástrojů a nových funkcionalit a nepoužívejte pro každou příležitost něco jiného. Nikdy to nebylo o technologiích, ale o vztazích a důvěře mezi lidmi a otevřeností. Stejně jako vám v klasickém světě stačila zeď a pár barevných lístečků a to jak na Refinement, tak i Planning a Retrospektivou, tak vám ve virtuálním světě stačí jeden flexibilní board, třeba Mural. A víc nepotřebujete. V jednoduchosti je síla.
Pro inspiraci, tady jako bonus krátké video a post o virtuálním světě školení.