Tag: Scrum tym

Deset formátů, jak vést retrospektivu

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

  1. Úvod: Novým týmům připomeňte, k čemu retrospektiva slouží, a co by mělo být na jejím konci, tedy konkrétní akční kroky, co jako tým zlepšíme. Když už je tým zvyklý retrospektivy pravidelně dělat, můžete přidat takzvaný ‘check-in’ na zvýšení energie například “Kdybyste byli počasí, jaké počasí byste byli?”. Takový check-in lze samozřejmě různě variovat a ptát se na typ auta, filmovou postavu nebo zvíře. Všichni se proberou a…
  2. Sběr dat: Další fáze sbírá od jednotlivých členů týmu data. Formát se liší, a v dalších článcích si projdeme nejčastější formáty retrospektivy. Často sesbíráte nápadů tolik, že je vhodné je seskupit do větších celků. Abyste od týmu získali zpětnou vazbu o tom, která témata je zajímají nejvíce, nechte je hlasovat. Například takzvaným dot-votingem, kde každý má řekněme čtyři hlasy a může je dát jednomu tématu nebo mezi různá témata rozdělit.
  3. Možnosti: V další části retrospektivy hledáme možnosti, co bychom s daným tématem, které je pro tým nejdůležitější mohli jako tým udělat. Nezapomeňte, že to vždy musí být potenciální akční kroky na tým, ne na někoho z venku týmu. Ideální je vymyslet alespoň pět nápadů. První tři jsou často nudné a nepřináší reálnou hodnotu ani kreativitu. Součástí vymýšlení možností může být i root-cause analýza abyste našli příčinu problému a neřešili symptomy.
  4. Akční kroky: Na závěr by se tým měl shodnout na jedné konkrétní věci, kterou příští Sprint udělá. Není nutné udělat všechno co nás napadne. Méně je často více. Když je kandidátů na výběr moc můžeme se týmu ptát, jak moc věří, že daná akce pomůže problém zlepšit, a jak moc věří tomu, že danou akci udělají. Obvykle pro tyto otázky volíme škálu 0 až 10, kde 0=nezlepší/neudělají a 10=vyřeší/určitě.

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…

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.

Nový Scrum Guide

Minulý týden se objevila nová verze ScrumGuidu. A zdá se, že je to cesta dobrým směrem. Popis je srozumitelnější, jednodušší a obsahuje méně detailů. Tady je pár rozdílů.

Scrum Guide

#1 – Scrum Guide 2020 je jasnější

Scrum Guide 2020 je jednodušší a jasnější. Konečně je psán srozumitelným jazykem a jasně popisuje co je Scrum. A protože Scrum je jednoduchý, je příjemné vidět že Scrum Guide může být také jednoduchý. Konečně se dobře čte a konečně jsme se zbavili přílišných detailů, jakým byly tři otázky na Daily Scrumu. Po mnoha letech neporozumění, kdy týmy brali Daily Scrum jako meeting kde každý reportuje svůj status, doporučuje Scrum Guide týmům vybrat si jakoukoli formu která jim pomůže lépe spolupracovat a maximalizovat hodnotu vzhledem ke Sprint Goalu. Za mě naprosto super.

#2 – Vše je o mindsetu

Líbí se mi, že nový Scrum Guide vypichuje tři pilíře emiricismu (transparentnost, inspection, adaptation) jako důležitou součást Scrumu spolu s pěti hodnotami Scrumu – commitment, focus, otevřenost, respekt, a odvaha a že se upřednostňuje to jak se lidé chovají před procesy a praktikami.

Další dobrou věcí je připomenutí, že Scrum se hodí primárně pro řešení komplexních problémů v nepředvídatelných prostředích a že různé techniky odhadování, měření velocity a kreslení burndown grafů se sice může zdát na první pohled užitečné, ale ve Scrumu upřednostňujeme schopnost rychle se měnit na základě zpětné vazby, tedy empirický přístup.

#3 – Scrum Team Focus

Největší změnou je to, že Scrum tým netvoří “Development tým”, ScrumMaster a Product Owner, ale “Developers”, ScrumMaster, a Product Owner. Vypadá to zdánlivě jako velká změna, ale není tomu tak. V obou případech všichni spolupracovali na maximalizaci hodnoty vzhledem ke Sprint Goalu, takže se vlastně nic nemění, jen jsme se snad nadobro zbavili typického nepochopení Scrumu, kde tým dodával Product Ownerovi a bral ho jako nepřítele. Teď je explicitně řečeno, že jsou na prvním místě týmem a že na výsledné hodnotě spolupracují. Tedy žádný dodavatel – odběratel vztah, ale cross-functional tým, co táhne za jeden provaz. Jsou v tom spolu.

Jediná vada na kráse je, že ‘Developer’ je dost nešťastně zvolené jméno, protože většině lidí asociuje software developera. Lepší výraz by asi byl ‘product worker’, tedy někdo, kdo na produktu pracuje a má potřebné znalosti a zkušenosti k tomu, aby týmu pomohl dodat end-to-end hodnotu pro zákazníka. Developeři jsou stále ti, kteří každý Sprint dodávají funkční produkt, zatímco Product Owner se zaměřuje na maximalizaci hodnoty a ScrumMaster na zlepšení fungování organizace a týmů.

Nový Scrum Guide přináší také jasnější doporučení pro scaling “Když by byl Scrum tým moc velký, můžete zvážit jeho rozdělení do více cross-functional Scrum týmů, které spolupracují na jednom produktu. V takovém případě týmy sdílí Product Goal, Product Backlog, a Product Ownera.”

#4 – Product Goal, Sprint Goal, a Increment

Konečně poslední změnou je přidání cíle produktu (Product Goal), lepší vysvětlení cíle Sprintu (Sprint Goal) a zjednodušení popisu Incrementu. Změny nejsou v praxi nové ale Scrum Guid zde dost pokulhával za běžnou praxí. Nový Scrum Guide nám take dává jistou definici produktu, která je mnohem širší, než si mnoho organizací myslí: “Produkt je nástrojem, který přináší hodnotu. Má jasnou hranici, známé stakeholdery, dobře definované uživatele nebo zákazníky. Produktem může být služba, fyzický produkt nebo něco abstraktnějšího.“ Product Goal je pro Scrum tým dlouhodobým cílem a vizí. Sprint Goal dává každému sprintu smysl a definuje hodnotu, na kterou se nyní zaměřujeme. Increment je funkční produkt který je kvalitně zpracován, otestován přináší hodnotu vzhledem ke Sprint Goalu. Jednoduché a jasné. Konečně také existuje mnohem lepší popis Definition of Done: „V okamžiku, kdy Product Backlog Item splňuje Definition of Done, zrodí se Increment.“

Celkově se mi nová verze Scrum Guidu opravdu líbí. Na tom, co jsem učila a používala, se nic moc nemění, přináší ale jasnější a čistší definici Scrumu, tak jak ho znám. A to je určitě dobře.