Facilitace je klíč úspěchu

Posledních několik blog postů jsem tady psala o Scrum Eventech a Refinementu. Mají jedno společné. Jsou o spolupráci a vyžadují dobrou facilitaci. Když jsem začínala, myslela jsem si, že facilitace je o technikách. Vybrala jsem si pár a ty jsem se naučila. A že jich je. Dám vám pár příkladů na ukázku.

  • Checkin facilitační technika se hodí na začátek abyste zvedli energii v týmu, všichni promluvili. Použít můžete spoustu technik od klasického Weather checkin – kdybyste byli počasí/auto/filmová postava, jaké počasí/auta/filmové postavy byste byli až po různé hry. Základ je ale jednoduchost, rychlost a zábavná forma.
  • Round-robin facilitační technika – kde dáte týmu třeba míček, plyšáka, nebo fixu, a oni si sami určují kdo bude mluvit. Mluví jen ten, kdo má míček a až skončí, hodí ho dalšímu. Všichni tak mají možnost promluvit, ale tým si sám řídí, kdo bude další. Ve virtuálním světě tato technika funguje stejně. Jen přijdete o zábavu s házením vtipného předmětu a ten kdo mluví jen jednoduše řekne kdo je další.
  • Brainstorming facilitační technika se používá na sběr dat o dané oblasti. Sbírat můžete nápady, problémy, zlepšení, obavy,… Forma brainstormingu je flexibilní, můžete diskutovat, nápady zapisovat, generovat postit možnosti na zeď, tabuli, Miro/Mural board, můžete nechat lidi brainstormovat po skupinkách a pak výsledky prezentovat nebo to dělat ve skupině. Vše je možné.
  • Dot-voting je jednou z mnoha technik, kde potřebujete ze spousty nápadů udělat výběr důležitějších, kterým se pak budete věnovat v detailu. Každý má několik hlasů, řekněme tři, a ty může volně rozdat tématům. Klidně i všechny jednomu tématu které je pro něj nejdůležitější. Na papírové postity děláme tečky, odtud vznikl název dot-voting. Virtuální tabule jako je Mural a Miro vabízí dot-voting jako běžnou funkcionalitu.

A tak bych mohla pokračovat. Bez dobré facilitace se v agilním světě neobejde ani ScrumMaster ani Product Owner a ve finále nikdo kdo chce spolupracovat s ostatními. Je to nástroj, který v agilním prostředí potřebují umět manageři i členové týmu.

Ale to hlavní není o technikách. To, co dělá facilitátory úspěšnými, je umění vnímat co se ve skupině děje, pracovat s energií, předcházet konfliktům, utdžovat zdravé prostředí. A to je teprve to pravé umění.

Chcete se stát skvělým facilitátorem a vyzkoušet si facilitaci na praktických ukázkách z agilního světa? Agile Facilitation workshop je tím pravým začátkem.

Jak dělat Backlog Refinement

Když už jsme prošli všechny Scrum Eventy, zbývá se ještě zastavit u Backlog Refinementu. Některé firmy mu říkají Grooming, ale na jménu nakonec nesejde. Cílem je vytvořit Product Backlog v rozumné granularitě aby byl vidět výhled a tým měl připravenou práci na dva až tři Sprinty dopředu. Víc není potřeba, nebylo by to přehledné. A protože kažný Sprint tým několik položek Backlogu dokončí, musí každý Sprint několik větších kusů rozpadnout na menší a důležitější. Backlog Refinement tedy běží průběžně, tak jak je potřeba.

Klíčem k úspěchu je si uvědomit že Refinement je hlavně o spolupráci. Položky backlogu by nikdy neměly vznikat v izolaci. Tedy nepíše je Product Owner a nepředává je hotové týmu jak si někteří často myslí, ale je to o spolupráci a spoluvytváření. Kdo tedy položky backlogu píše? Všichni. Product Owner, zákazníci, stakeholdeři a členové týmu kterým ve Scrumu říkáme developers – tedy business analytici, developeři, testeři, designéři, … . Refinement probíhá různě. Někdy pozvete všechny na workshop, kde společně rozmyslí a rozpadnou několik položek backlogu, někdy se sejde jen pár členů týmu a spolu se zákazníkem začnete nějakou oblast popoisovat, a přemýšlet o potřebách které musí pokrýt. Jindy menší skupinka nějakou část produktu rozpadne na menší a jasnější kousky. Není to ani pravidelně naplánovaná aktivita tedy Scrum Event, není ani centralizovaná. Naopak. Zůčastní se ti co se potřebují zúčastnit, v čase, kdy je to potřeba. Ad hoc. Velmi agilní. Nicméně na konci dne musí celý Scrum tým rozumět jednotlivým položkám backlogu v dané granularitě a chápat jejich priority. Refinement tedy potřebuje jako pre-requisitu self-managing cross-funcitional tým. Self-managing proto, aby převzal za refinemnt vlastnictví a zodpovědnost a cross-funcitional aby měl potřebné znalosti a skily.

Role Procuct Ownera tedy není jako zapisovatel, ale spočívá spíše ve výběru vhodných účastníků a facilitaci společné spolupráce než psaní samotných storek. Product Owner Je často facilitátorem spolupráce, dává konverzaci směr a smysl. Product Owner dle potřeby může vždy požádat o facilitaci ScrumMastera, ale umění facilitace dělá refinement významně snažší.

Scrum Eventy: Sprint Review

Sprint Review je klíčovým prvkem Scrumu. Probíhá na konci každého Sprintu, aby Scrum tým zjistil, jestli jde správným směrem. Nutnou podmínkou úspěchu je dodávat hodnotu, ne jen nahodilé technické tásky.

Cíl: Získat zpětnou vazbu od zákazníků, případně interních stakeholderů.

Délka: Podle počtu týmů a zákazníků bude Sprint Review trvat něco mezi 15 min a dvěmi hodinami (pro produkty dodávané více týmy).

Jak: Hlavní je si uvědomit, že cílem Sprint Review není akceptace, ale zpětná vazba od zákazníků.

  • Sprint Review není prezentace pro Product Ownera, ten je součástí Scrum týmu a na Sprint Review společně s Developery ukazují hodnotu zákazníkům.
  • Členové týmu prezentují zákazníkům hodnotu, kterou dodali, nikoliv technické řešení. Zákazníci dávají týmu zpětnou vazbu.
  • Na zpětnou vazbu není třeba nijak reagovat, jen ji pochopit. Co s danou funkcionalitou uděláme je součástí Backlog Refinementu.
  • Je vhodné, aby Product Owner neprezentoval, ale byl dobrým posluchačem a zaměřil se na získání zpětné vazby.
  • Sprint Review není o prezentaci, ale o zpětné vazbě. Často tedy místo ukazování funkcionality necháte zákazníky produkt používat a díváte se, jak s produktem pracují.
  • Na Sprint Review musíte pozvat ty stakeholdery a zákazníky kteří vám na danou funkcionalitu mohou dát relevantní zpětnou vazbu.

Scrum Eventy: Sprint Planning

Na začátku každého Sprintu tým říká, co si myslí že dokončí, tedy vybírá Sprint Backlog. Je to taková předpověď toho, co asi budou dělat, tedy je možné ji kdykoliv v průběhu Sprintu změnit. Tým se ale zavazuje, že udělá maximum pro dosažení cíle Sprintu, který se naopak v průběhu Sprintu nemění.

Cíl: Na Sprint Planning přichází Product Owner se Sprint Goalem na základě kterého potom členové týmu (Developers) vybírají Sprint Backlog a domlouvají se, jak budou jako tým spolupracovat.

Délka: Když tým rozumí Product Backlogu, business hodnotě jednotlivých položek backlogu a prioritám je Sprint Planning je poměrně jednoduchý a netrvá déle než dvacet minut. Když ovšem tým dělá Backlog Refinement až na planningu, takový Sprint Planning trvá klidně i několik dní.

Jak na to: Prerequisitou Sprint Planningu je dobré porozumění Backlogu. Prioritní položky Backlogu by měly být připravené v takové kvalitě, aby tým rozuměl dané potřebě zákazníka a věděl, jak jí bude řešit.

  • Sprint Planning je dobré vizualizovat například na Scrum Boardu, aby všichni členové týmu viděli, co plánují dělat.
  • Začínající týmy si většinou na planningu rozpadnou vybrané položky Backlogu na konkrétní tásky aby každý člen týmu rozuměl konkrétním činnostem a lépe se jim plánovalo, jak na dané položce backlogu budou spolupracovat.
  • Sprint Goal se během Sprintu nemění, položky Sprint Backlogu a tásky se mohou měnit kdykoliv existuje lepší cesta, jak maximalizovat hodnotu vzhledem ke Sprint Goalu.
  • Sprint Goal je pro Sprint jenom jeden, aby určoval směr, položek Sprint Backlogu může být více. Obvykle týmy plánují 3-5 položek backlogu na Sprint, kde ta největší by měla být týmem dokončitelná maximálně za půl Sprintu.
  • Sprint Goal je řízený potřebou zákazníka, Sprint Backlog naopak definuje, co můžeme udělat my abychom potřebu zákazníka naplnili. Tásky potom reprezentují konkrétní činnosti například business analýzu, změnu backendu, frontendu, testování apod.

Jak na Scrum Eventy

Když to řeknu jednou větou, Scrum je iterativní a inkrementální styl práce, zaměřený na týmovou spolupráci a maximalizaci business hodnoty. Nic složitého. To ale neznamená že ho organizace hned napoprvé implementují správně. Scrum totiž mění poměrně hodně zažitých věcí. Tentokrát bych se chtěla podívat na eventy. A jen tak mimochodem, neříkáme jim ani “ceremonie“ (které týmy dělají jen tak naoko, protože Scrum říká že se to musí), ani “meetingy“ které někdo pro tým musí zorganizovat. Event je bližší slovu “happening“. Tedy něčemu, co se děje skoro by se dalo říct samo od sebe, protože všichni chtějí, aby se to dělo. Nikde se nic nemusí plánovat, všichni vědí, kde a kdy event je a účastní se, protože jim to připadá užitečné a smysluplné.

Eventů je ve Scrumu pět a se dějí pravidelně. Mají sice definovanou maximální délku, ale je dobré vědět že pro kratší Sprinty eventy trvají významně kratší dobu. Důležitá je hlavně pravidelnost. Tím, že se dějí pravidelně, pomáhají týmu ale i zákazníkům si na iterativní styl práce zvyknout a lépe plánovat, připravovat se, a vědět co se děje.

Asi nejčastější problém je, že se týmy snaží aplikovat Scrum na jednotlivce místo na tým a že v Product Backlogu mají nahodilé tásky, nikoliv položky backlogu definující business hodnotu. V takovém prostředí většina eventů nefunguje, protože jsou založené na týmové spolupráci a dodávání hodnoty. Ze Sprint Planningu se stane alokace práce pro jednotlivce, z Daily Scrumu se stává micromanagerský otravný meeting, Sprint Review ukazujeme jen tak sami sobě, protože drobné činnosti vlastně nikoho nezajímají, a na Retrospektivě si postěžujeme, jak nám ten Scrum nefunguje. Nic, co byste chtěli zažít. A nemá ani moc cenu nutit jednotlivce Scrum eventy vykonávat, dokud místo skupiny jednotlivců nemáte tým a dokud v Product Backlogu nemáte opravdové položky backlogu zaměřené na hodnotu. V momentě, kdy se tyto dvě věci spraví, dějí se eventy vlastně samy od sebe, protože týmu pomáhají se lépe zorganizovat a dosahovat větší hodnoty pro zákazníka.

Když budete mít tým a relevantní Product Backlog, zbývá už jen vysvětlit k čemu jednotlivé Scrum eventy jsou a jak by měly vypadat. A na to se podíváme v následujících příspěvcích: Sprint, Sprint Planning, Daily Scrum, Sprint Review, Retrospektiva.

Jak hodnotit ScrumMastera

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ě.

Scrum jen naoko

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?

  1. Definujte business hodnotu: Jakou máme vizi, čeho chceme dosáhnout a pro koho?
  2. Najděte Product Ownera, který rozumí businessu, hodnotu vnímá, a je schopen se rozhodnout co uděláme teď, a zbytek později, nebo nikdy. Tomu dejte zodpovědnost za úspěch – tedy nejen dodávku ale i návratnost (ROI) produktu.
  3. Postavte malé týmy, které dokáží hodnotu dodat end to end. Dejte jim autonomii se rozhodnout jak budou spolupracovat.
  4. Dejte jim ScrumMastera (coache, ne projektového managera) aby jim pomáhal hledat lepší cesty fungování.

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á.

Konflikt je kořením dobré konverzace

Konflikty jsou mezi lidmi běžné. ScrumMasteři ale mají často pocit, že konflikty jsou něčím špatným, něčím, čemu je dobré se vyhnout. Když ale všichni se vším souhlasí, týmu chybí rozmanitost pohledů a kreativita. Na první pohled tým vypadá zdravě, ale obava z konfliktů jim neumožňuje věci rozebrat z více úhlů. Taková prostředí často postrádají energii a jsou v dlouhodobém horizontu méně úspěšná než ty, kde se konflikty objevují pravidelně.

Cílem ScrumMastera je postavit dobře fungující, self-organized nebo chcete-li self-managed tým. Schopnost konflikty zvládat je jednou z vlastností dobře fungujícího týmu. Diversita je klíčem úspěchu v komplexním světě. Takže co takový ScrumMaster potřebuje umět, aby tým na jejich cestě podpořil a nezašlápl je do stavu umělé harmonie, kde naoko všichni se vším souhlasí a nic nechallengují, ale tým se nerozvíjí a nezlepšuje? První co mi přišlo na mysl je facilitace, tedy „technika, která umožní dovést skupinu k cíli porady či složitého jednání navzdory úskalí neefektivní komunikace, nedorozumění a nejasností mezi účastníky.“ Jak facilitaci definuje asociace mediátorů. „Facilitátor je odborník na vedení procesu dorozumívání se, který zaměřuje energii účastníků na dané téma a volí metody jednání dle aktuální situace, vždy však tak, aby umožnil každému aktivně se zúčastnit a vyslovit svůj názor v bezpečné atmosféře. Zodpovídá za proces dorozumívání, nikoliv za výsledky řešení.“

Jednou ze základních vlastností facilitátora je neutralita. Facilitátor neurčuje o čem lidé mluví, ale jak o tom mluví. Stará se o prostředí, posiluje otevřenost a důvěru mezi lidmi. Umí diskusi rozproudit, nebo naopak pomoci skupině konvergovat k určitému konkrétnímu tématu. Facilitace není jen o nástrojích, ale o schopnosti vnímat energii a pomoci týmům vést efektivní dialog. Dialog, kde spolu lidé nejen souhlasí, ale často přicházejí i s opačnými názory. Nebojí se konfliktu a jsou ochotni nesouhlas vyslovit.

Four Player Model

Jeden z mých oblíbených konceptů, který při facilitaci dialogu používám, se jmenuje model čtyř hráčů (Four Player Model). Popisuje čtyři možnosti interakce mezi lidmi. První interakcí je takzvaný hybatel (Mover), tedy ten, co určí směr, přijde s novým nápadem, uvede věci do pohybu. Druhý typ interakce je následník (Follower), tedy ten, co následuje toho, kdo s nápadem přišel, souhlasí s ním a podporuje ho. Třetí interakcí je oponent (Opposer) který nesouhlasí a nápadu oponuje, zpochybňuje ho, klade otázky. Poslední interakce je takzvaný pozorovatel (Bystander) který se na věci dívá z nadhledu, dokáže udělat přehled možností a sumarizovat situaci, aniž by se k jedné myšlence přiklonil. Správně fungující tým potřebuje rovnováhu všech čtyř možností interakce a dobrý ScrumMaster by měl být schopen v týmu takové rovnováhy dosáhnout. Konflikt je kořením dobré konverzace. Bez něj je konverzace plochá, bez energie, bez kreativity a inovativní řešení nikdy nevzniknou. Ve světě, kde se očekává, že zaměstnanci budou slepě vykonávat příkazy a následovat procesy, se konflikt bere jako drzost a zbytečná neefektivita. V agilním světě, který staví na autonomii a spolupráci v rámci týmu je umění dialogu za použití všech čtyř interakcí nezbytné k úspěchu. Takže se konfliktů nebojte a naučte se je využívat ve prospěch týmu.

ScrumMaster není asistent týmu

Když se podíváte na inzeráty hledající ScrumMastery, bohužel až příliš často najdete popis role, která místo ScrumMastera hledá spíše asistenta týmu. O tom, jak hledat ScrumMastera jsem tu už psala, takže dnes se podíváme na příčinu takového nepochopení. Jak vám většina lidí řekne, ScrumMaster má odstraňovat překážky. A pod tím si bohužel většina těch, co Scrumu a roli ScrumMastera nerozumí, představí právě toho asistenta. Takže co ta věta, že ScrumMaster odstraňuje překážky vlastně znamená? Pro porozumění se musíme vrátit k hlavnímu smyslu existence ScrumMastera. Cílem ScrumMastera je stavět dobře fungující samoorganizované týmy. A jak to, že týmu budete dělat asistenta pomůže týmu stát se selforganized? Nojo, nijak. Takže o čem to odstraňování překážek vlastně je? Překvapivě ne o tom, že je nebudete odstraňovat sami, ale že pomůžete týmu, aby si uvědomili, že si je dokážou odstranit sami. Tým je zodpovědný za to, že se zorganizuje tak, aby maximalizovali hodnotu vzhledem ke Sprint Goalu, tedy vlastní celý proces, a do toho patří i to, že se postarají, aby překážky nějak odstranili. ScrumMaster tedy není asistentem, ale servant leaderem. Pomáhá týmu převzít za své věci zodpovědnost a vlastnictví a stát se tak lepším týmem. Je coachem, pomáhá týmu si uvědomit kde problém je a jaké vidí možnosti řešení. A je facilitátorem, pomáhá týmu identifikovat příčinu a nevysilovat se řešením symptomů. Takže jestli jste si právě uvědomili., že většinu problémů za tým řešíte vy, vězte, že jim tím děláte medvědí službu a bráníte jim v tom, aby se stali lepším high-performing self-organized týmem. Zůstanou zaseklí tam kde jsou, a jen s tím, jak jde čas si začnou stěžovat, že oni za nic nemůžou a že to ScrumMaster měl… Není to moc pěkný obrázek. Dobrá zpráva je, že změna je snadná. Vysvětlete týmu, že dělat jim asistentky není vaším cílem ani zodpovědností a začněte více coachovat a facilitovat. Staňte se Servant leaderem, který věci za tým nedělá ani nerozhoduje, ale namísto toho vytvoří takové prostředí, že si je dokážou vyřešit sami. Občas to bolí, ale přináší to výrazně lepší výsledky.

Retrospektiva není pro stížnosti

Jednou z nejdůležitějších věcí, které Scrum zavádí do firem je Retrospektiva. Učí nás brát chyby a neúspěchy jako dobrou věc, tedy jako příležitost ke zlepšení. Co když se nám nepovede dobře se zorganizovat a nic na konci Sprintu nedodáme? Nevadí. Na konci Sprintu si dáme Retrospektivu, a zamyslíme se nad tím, co příště uděláme jinak, aby se nám to už nestalo. Co když toho tři Sprinty za sebou naplánujeme moc a pokaždé dodáme jen část? Dáme si Retrospektivu a zamyslíme se nad tím, jak změníme plánování Sprintů tak, aby odhad více odpovídal realitě. Některé věci jsou akutní a bolestivé a dostanou se na retrospektivu hned, jiným to chvíli trvá. Ale když se budou dít pravidelně, dříve či později je někdo bude považovat za tak otravné, že je zmíní. Retrospektiva ale není o tom si postěžovat a odejít, ale příležitost pro zlepšení. Proto každá Retrospektiva věnuje většinu času nikoliv stížnostem, co všechno nefunguje, ale hledání příčin proč se to děje a následně možností, co bychom s tím jako tým mohli udělat příští Sprint. Každá Retrospektiva proto musí končit alespoň jedním konkrétním krokem co tým udělá příští Sprint jinak, aby se daná oblast zlepšila. Nemusí se hned vyřešit, ale každé zlepšení se počítá. Obecně platí, že když máte takových akcí moc, často se tým rozptýlí a neudělá nic. Proto by takových akčních kroků nemělo být příliš. Vyberte si jen to nejdůležitější a s tím pohněte. Jednu dvě, maximálně tři akce. Příští retrospektivu si zase můžete vybrat něco jiného, nebo v tom stejném tématu pokračovat, podle důležitosti.

Kdyby vás retrospektiva zajímala, můžete si pustit mé video. Je starší, ale stále platné 🙂