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é 🙂

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.

Proč Scrum ve firmách nefunguje

Čas od času přijde někdo a říká, že Scrum nefunguje a že oni jsou agilní a to že je lepší. Dovolím si oponovat. Ne proto, že by někdo nemohl být agilní bez Scrumu, ale proto, že teorie a realita jsou obvykle dost daleko od sebe a Scrum je zatím stále nejjednodušší a nejúspěšnější cesta, jak se stát agilními. Nemusíte souhlasit, ani pokračovat ve čtení. Ani jedno není povinné. Ale jestli vás zajímá můj názor na to, proč Scrum v některých prostředích nefunguje, tak tady je hned několik nejčastějších důvodů. Není to o businessu, ve kterém jste, ani o velikosti. Dobrá zpráva je, že všechny jsou snadno řešitelné, jak jinak než implementaci opravdového Scrumu, nikoliv fake-Scrumu, nebo “DarkScrumu“.

#1: Neexistence týmu

Nejčastějším důvodem, proč Scrum nefunguje je, že nemáte tým. Lidi pracují každý na svých úkolech, jako jednotlivci. V takovém případě se vytrácí celá podstata Scrumu a zbudou nesmyslná pravidla a “DarkScrum“ je temně černý. Tým je podstatou kvality, motivace, schopnosti adresovat komplexní problémy a nacházet inovativní řešení. Jak se tedy liší tým od skupiny jednotlivců? Tím že spolupracuje. Je postavený na důvěře, schopnosti nebát se říct si věci do očí, k něčemu se společně zavázat, vzít za věci zodpovědnost, a mít jeden společný cíl (viz kniha Five Dysfunctions of a Team). Začít můžete tak, že tým má jeden společný Sprint Goal (businessovou vizi sprintu), která je spojuje a společně plánuje, jak by v rámci Sprintu tuto hodnotu mohli maximalizovat (forecast). Když nechcete aplikovat rovnou mob-programming a pracovat všichni najednou na jednom úkolu, jednom počítači a jedné klávesnici, dobrou praktikou pro posílení spolupráce je “one story at a time“ kde celý tým spolupracuje na různých úkolech jedné konkrétní položky backlogu alias story a teprve když ji dokončí, dá se společně na další. Tým na to nepotřebuje žádného manažera ani asistenta, organizuje se sám. Dobrá zpráva je, že na to, abyste měli skvěle fungující self-organized tým je tady ScrumMaster.

#2: Komponent týmy

Kromě toho že je to self-organized tým, musí být také cross-functional. To neznamená že každý umí všechno, ale že jako tým mají všechny potřebné znalosti a zkušenosti k tomu, aby mohli vzít libovolnou položku backlogu a tu dokončit. Sami, bez dependencí na kohokoli jiného. Klasicky smýšlející organizace se často takové bojí týmy postavit. Většinou za tím stojí strach o ztrátu moci, nebo limitující kontrakty s dodavateli a obava je změnit. Firmy proto končí s komponentně orientovanými týmy, které i při nejlepší vůli nedokážou udělat nic, co by za něco stálo a dokázalo se prezentovat zákazníkům na Sprint Review, ze kterého se stává bezduchá akceptace dílčích kousků. Nic, na co by šla získat zpětná vazba. “DarkScrum“ je více či méně tmavě šedý, v závislosti na tom jak fragmentované jsou komponenty a ošklivé dependence. Stejně jako v minulém bodě, vysvětlovat důležitost a prosazovat cross-functional tým je na ScrumMasterovi.

#3: Nejasná business hodnota

Dalším bohužel docela častým problémem je to, že nikdo není schopen definovat business hodnotu. Divili byste se, kolik organizací není schopno definovat vizi. Je to frustrující, a obvykle to končí tím, že týmy říkají „dejte nám specifikaci, my to podle ní vyrobíme“. A “DarkScrum“ je černo-černý. Ve Scrumu totiž žádná detailní specifikace neexistuje. Máme jen vizi produktu, businessově orientovaný Sprint Goal a businessové položky backlogu, které nejsou zaměřené na implementaci, ale na business value. Implementace je velice flexibilní a je na týmu ji v rámci Sprintu vymyslet tak, aby se hodnota dodaná v daném Sprintu maximalizovala. To je ostatně rolí Product Ownera, který musí mít autoritu rozhodnout o prioritách, a být schopen upřednostnit tu část Backlogu, která přináší nejvyšší hodnotu.

#4: Proč bychom se měli měnit?

Asi posledním z důvodů, proč vám Scrum nefunguje, ale kterým byste asi měli začít, je uvědomit si proč byste se měli měnit. Co se stane, když se nezměníte. Že nebudete agilní? No to asi nikomu nevadí. Agile není váš cíl, ale jen cesta, jak se k němu dostat. A Scrum není jediná možnost jak se agilními stát. Jen podle mne ta nejefektivnější a nejúspěšnější. Jak říká guru change managementu John Kotter, když chcete, aby změna byla úspěšná, musíte vytvořit pocit nutnosti, neodkladnosti, urgentnosti.  Lidi ani organizace se nemění, protože někdo vymyslel nový proces. Mění se, protože musí. Není to o tom, jestli se vám současný proces líbí nebo ne, pomáhala jsem změnit se firmám, které milovaly waterfall. Ale jediné firmě, které pomoct neumím je té, co nechce. Bez pocitu, že změnu nutně potřebují se žádná změna nestane. Je to moc práce. A změna kultury a mindsetu, kterou Agile a Scrum přináší je ta nejtěžší, kterou znám. Jestli se tedy chcete už v začátku vyvarovat stupňům šedi “DarkScrumu“, začněte s jasným důvodem, proč je změna nutná. Celá implementace bude pak výrazně méně náchylná k “tmavnutí“. Je to jako posílení imunity, jako vitamíny.

#5: Částečný Scrum

Jestliže předchozí odstavce jsou dané nepochopením, tohle je čistý alibizmus. Není to důvod proč Scrum nefunguje. Není to totiž Scrum. V angličtině se tomu říká Scrum-but. Tedy “my máme Scrum, ale neděláme retrospektivy. My máme Scrum, ale nemáme ScrumMastera, my máme Scrum, ale nemáme cross-functional týmy“. Nikdo vás nenutí Scrum nasadit, ale když už se do toho pustíte, tak buď pořádně, anebo vůbec. To, že nějaký paskvil nazvete Scrumem nepomůže ani vám, ani ostatním. Ba právě naopak. Ostatní odradí od toho to zkusit pořádně a vám přinese jen tu nejčernější verzi “DarkScrumu“.

Jeden produkt, jeden Product Owner

Jeden z nejčastějších dotazů je, proč má být ve Scrumu jeden Product Owner na celý produkt, proč na každý systém není jiný Product Owner (tedy proč nemáme komisi Product Ownerů) popřípadě proč každý tým nemá svého Product Ownera (team PO, proxy PO). A když už tedy máme jednoho PO jak to může všechno stihnout.

Začneme od začátku. Jednoho PO máme, protože máme jeden produkt. A ten potřebuje pro svůj úspěch jasný směr, jasnou vizi na jejímž základě má každý produkt jeden prioritizovaný backlog na základě business value. Komise je těžkopádná, nemá na věci jednotný pohled a jen těžko se domluví. Obvykle končí doporučením, že tohle všechno musíte udělat jako prioritu jedna. Tedy máte skupinu stakeholderů (nebo zákazníků, jak je v agilním světě nazýváme), ale žádného Product Ownera. Konsekvence je nekvalitní backlog, nejasné priority a zákulisní boje. Týmový /Proxy Product Owner je zase nešvar, který jsme zdědili z klasického vnímání development týmu jako tzv. ‘Coding monkeys’ tedy codérů, kteří tupě nakódují co někdo jiný naspecifikoval bez toho, aniž by jakkoli přemýšleli, jestli daná implementace vede k cíli. V lepším případě component týmů (které mají na starosti jen určitou část systému) a nedokážou tak žádnou hodnotu dodat. Když týmy nedodávají end-to-end hodnotu, nemůžou získat relevantní zpětnou vazbu a celé Sprint Review je zbytečné. Component týmy nemají dostatečný přehled o celkovém businessu, požadavkům ve formě user story nerozumí, a tak požadují, aby jim někdo napsal detailní akceptační kriteria /specifikaci, aby věděli co se má v dané komponentě udělat. A protože businessově orientovaný PO věcem technicky nerozumí a ani na to nemá čas, instalují asistenta, který jim to připravuje. A jsme zpět ve waterfallu. Nejdřív se udělá specifikace, pak podle ní vyvíjí produkt. Takže tudy cesta také nevede. Tedy jestli chcete zůstat v tradičním světě, proč ne. Rozhodnutí je na vás. Jestli ale chcete aplikovat Scrum tak jak byl zamýšlený, a hlavně tak aby fungoval, odpověď je snadná.

Backlog Refinement is about collaborationJeden produkt (a o tom jak se takový produkt definuje už jsem tu psala) má jednu vizi, jeden backlog, a tedy i jednoho PO. Na produktu může pracovat několik cross-functional týmů, které každý za sebe dokážou dodat end-to-end hodnotu, tedy plně funkční produkt. Aby to jeden PO zvládal, nepracuje sám, ale v rámci backlog refinementu mu pomáhají již zmíněné týmy, které společně s PO a zákazníky backlog připravují a starají se o to, že všichni rozumí prioritám i jednotlivým položkám backlogu. Asi nejčastější chybou, která k výše zmíněnému ‘fake PO’ vede je představa, že Product Owner píše položky backlogu, které když jsou ready předává týmu a ten je podle jeho požadavků naimplemetuje. Tak to ale ve Scrumu být nemá a nikdy být nemělo. Refinement je týmová práce a podílí se na ní všichni. Zákazníci, stakeholdeři, uživatelé, cross-functional týmy, a Product Owner a položky backlogu definují společně.

Když to celé zjednoduším. Scrum je o týmové spolupráci (nejen v rámci Scrum týmu ale i se zákazníky), jasných prioritách (proto máme jednu hlavu, jednoho Product Ownera) a dodávání hodnoty (cross-functional týmy).

Sprint Goal – příklad

Jedna z častých otázek je, jak má správně vypadat Sprint Goal. Pojďme se ale nejdřív podívat, co to je. Sprint Goal dává Sprintu smysl. Definuje, čeho chceme dosáhnout. Dává dostatečně silný důvod jeho existence. Proč by měl Product Owner do Sprintu investovat (čas i peníze). Vyplatí se to? Sprint Goal je nedílnou součástí prioritizace Backlogu. Sprint totiž není o dodání jednotlivých položek Backlogu, ale o dosáhnutí cíle Sprintu, tedy Sprint Goalu.

Sprint GoalJak by mohl takový Sprint Goal vypadat? Když o něm slyšíte úplně poprvé, můžete začít třeba Sprint Goalem, který je implementací větší položky Backlogu. Jako je třeba:

Ve Sprint Backlogu potom budou různé položky Backlogu, které tvoří jednotlivé části Dashboardu.

Sprint Goal: “Dashboard“ 

Příklad PBIs: “Tabulka s příjmy a náklady, graf cash-flow, semafor zdravosti financí, seznam nezaplacených faktur.“

Když budete chtít v pochopení Sprint Goalu pokračovat, tak o trochu lepším cílem sprintu je podívat se na to z pohledu business hodnoty a zákazníka a identifikovat tak potřebu, například:

Jednotlivými položkami Backlogu, které pak tým následně vybere z Backlogu budou nejen položky tvořící Dashboard, ale například notifikace, které užitečnosti přehledu o financích můžou přispět i více než samotný dashboard.

Spring Goal: “Zvýšit přehled o financích“

Příklad PBIs: “Tabulka s příjmy a náklady, graf cash-flow, semafor zdravosti financí, notifikace o překročených limitech, notifikace o fakturách po splatnosti“.

Na závěr už zbývá jen přidat příklad, jak by takový Sprint Goal nikdy vypadat neměl. “Dokončit PBI1, PBI2, PBI4 a PBI6 podle definice“. Takový Sprint Goal je příkladem tradičního mindsetu a naprostého nepochopení toho o čem Scrum je. Tedy zaměňuje Sprint Goal za konkrétní specifikaci, a Backlog za ToDo list. Ale ani jedno není Scrum. Scrum je takzvaně ‘purpose driven‘. Tedy řízený nějakým vyšším smyslem, něčím, co přináší hodnotu pro zákazníka. Něčím, do čeho byste byli ochotni investovat svoje peníze, abyste další Sprint zaplatili. A pak další, a další. Něco, čemu věříte natolik, že byste do toho šli.

ScrumMaster by měl pomáhat Product Ownerovi

Pryč je doba, kdy ScrumMaster byl v podstatě jen členem Development týmu, a Product Owner nepřítel, kterého bylo třeba vytlačit pryč. Naštěstí. Jak ScrumMasteři rostou a jejich týmy se stávají více a více self-organized, začínají mít více času věnovat se druhé úrovni #ScrumMasterWay konceptu. A jednou z částí je i pomáhat Product Ownerovi. Z čeho taková pomoc sestává? Tak za prvé dát pozor na to, že existuje jasná vize, a je pochopená jak development týmem, tak i stakeholder a zákazníky. Často samotná existence vize je problém, který trvá několik měsíců. Schopnost ji komunikovat a nadchnout pro ni, už nebývá tak složité. Zrovna tak jako Backlog Refinement, který se bez vize stává noční můrou, funguje v případě dobře definované vize v podstatě sám. Je to v podstatě o pár praktikách. Kdy píšeme položky Backlogu jako UserStory, kdy je lepší aplikovat Story Mapping, nebo Impact Mapping? Dobrý ScrumMaster by měl být schopen takové praktiky doporučit a také naučit, a následně takový workshop se stakeholdery být schopný i v případě potřeby facilitovat. A můžeme pokračovat, vědět, kdy prioritizujeme seřazením, kdy používáme některé z innovative games, kdy KANO, kdy relativní váhy. Metod je mnoho. A můžete se je učit donekonečna. Pořád budete nacházet další a další. A můžete říct, že to je přeci na Product Ownerovi, aby si našel to, co potřebuje. Ale když neví, obrátí se na experta a tím by měl být ScrumMaster, který se neustále vzdělává a je neustále o krok před týmem, Product Ownerem a organizací. ScrumMaster by měl být někým, kdo umí vždy poradit a nasměrovat. Kdo ví jak na to. Kdo je dobrým facilitátorem, aby dané metody dokázal poprvé týmu předvést a provést je jimi. Když to budete dělat dobře, Product Owneři si tyto praktiky brzy osvojí a budou si je facilitovat sami. A vám zbude více času na třetí úroveň #ScrumMasterWay konceptu – tedy celý systém. A o to vlastně jde.

Vychází kniha Skvělý ScrumMaster #ScrumMasterWay

Před časem jsem psala, že mi vyšla knížka The Great ScrumMaster: #ScrumMasterWay. Knihu jsem psala rovnou v angličtině, protože mi přišlo, že něco takového chybí nejen u nás, ale obecně ve Agilní a Scrum komunitě. Mám stále radost, že kniha nadchla Mika Cohna, který ji akceptoval do své signature řady a kniha tak mohla vyjít u velkého nakladatelství Addison-Wesley v USA.

Skvělý ScrumMaster #ScrumMasterWay

O českém vydání jsem moc nepřemýšlela, ale jak už to bývá, pomohla náhoda. Spíše asi dvě náhody. První bylo, že se knížka lidem líbí, dozvěděla jsem se, že se chystají její překlady – do ruštiny a čínštiny – a pak mluvila s lidmi při příležitosti vydání v těchto jazycích. Prostě fakt, že i v IT oboru stále spousta lidí radši čte ve svém lokálním jazyce a nakladatelství mají zájem překlady vydávat, ve mně zanechalo myšlenku, že by možná nebylo špatné vydat i českou verzi. A druhý moment, který tomu pomohl, bylo náhodné setkání s lidmi z Computer Pressu, kteří byli z této možnosti nadšení. A bylo rozhodnuto.

Cesta k českému vydání nebyla ve výsledku tak rychlá, jak jsem čekala, trochu se nám lepila smůla na paty, nejdříve s překladem do češtiny, který trval déle, než měl. A když už byl hotov, tak se mi nelíbil a v podstatě celý jsem ho přepsala. 🙂 Ale myslím, že nakonec čekání stálo za to – Computer Press investoval do pěkného vydání, kniha se vrací k původnímu barevnému čtvercovému formátu, takže se můžete těšit na celostránkové barevné ilustrace, jako v původní self-published edici, což mi udělalo velkou radost.

Kniha “Skvělý ScrumMaster #ScrumMasterWay” by se měla objevit na trhu každým dnem, na konferenci Agile Prague bych měla mít první výtisky k dispozici. Tak doufám, že vše klapne, knížka se objeví na trhu co nejdříve a hlavně se vám bude líbit. Více na webu vydavatele či eshopu vydavatele.

Český překlad Scrum Guidu

V rámci české agilní komunity vznikl český překlad Scrum Guidu, tedy ‘Průvodce Scrumem‘. Takže kdyby se vám nechtělo Scrum Guide číst v originále, tohle je poměrně povedená aktuální česká verze, která zachovává normálně používané termíny Scrumu, takže se nemusíte bát, že byste se v ztratili překladu jako já nedávno, když jsem dostala od vydavatele českou verzi své knihy The Great ScrumMaster: #ScrumMasterWay na review a musela se dívat do angličtiny co že to vlastně píšu. Takže nejen Scrum Guide, ale i kniha bude. Už jsem ji přepsala zpět do původního významu a čekam na finalni versi od Computer Press. Jupiiii 🙂

Asi o to víc oceňuji práci, kterou si s tím autorky překladu (viz poslední stranka dokumentu) daly. Když k němu budete mít nějaké připomínky, budou určitě rády za feedback a slibují, že ho zohlední. Děkujeme 🙂

Podpořte svého ScrumMastera – kupte mu Vánoční dárek

Začíná čas adventní a blíží se pomalu Vánoce a ze všech možných zdrojů se můžeme dozvědět, jaké dárky pořídit manželovi/manželce, příteli/přítelkyni, rodičům, prarodičům, dětem. Ale na ScrumMastery jako by se zapomnělo, mi tedy přijde. Nikde jsem neviděla tipy na dárky pro ScrumMastery a tak jsem se to rozhodla napravit 🙂 Tak to berte jako oddychový předvánoční blog post s trochou reklamy, která se třeba může někomu hodit.

The Great ScrumMaster: #ScrumMasterWayZákladem dobré práce jsou znalosti a zkušenosti. A jedním z možných zdrojů jsou knihy. Doporučím svoji knihu The Great ScrumMaster: #ScrumMasterWay, protože si myslím, že se fakt povedla a hlavně mám na ni dobré feedbacky. Hlavně tím, jak je praktická a jde k jádru věci. Pokud někdo v Agilu tápe a chce širší rozhled, tak v češtině má prvotina Agilní metody řízení projektů je stále uceleným zdrojem informací. Pokud nevadí angličtina, určitě za zmínku stojí Essential Scrum od Kennetha Rubina. Pokud se chcete posunout dál, tak doporučuji Coaching Agile Teams od Lissy Adkins, která je skvělá koučka. Kniha trochu hutnější, ale už se nejedná o basic úroveň. A pokud se chce někdo posunout do multitýmového prostředí, tak kniha o LeSSu Large-Scale Scrum: More with LeSS je ‘must’ – obsáhla, dlouhá, informačně výživná. A Craig s Basem jsou prostě skvělí Scrum a LeSS traineři, od nich je radost se učit.

Pokud vás čtení nebaví a máte radši informace získané rychleji i s praktickou ukázkou, přijďte na školení. Pro ScrumMastery je určitě základem CSM – Certified ScrumMaster, kde se dozvíte jak se v roli ScrumMastera posunout dál a navíc získáte certifikaci, které má fakt hodnotu. Pokud CSM už máte či vám přijde, že to je moc basic (ale to moje fakt není) tak přijďte na Certified LeSS Practitoner školení, kde se ve 3 dnech dozvíte jak na scaling, produkty atd. Super advanced školení. A pokud chcete mít náskok a z role ScrumMastera se posouváte dál a potřebujete se na organizaci dívat více z managerského pohledu, tak CAL1 – Certified Agile Leadership bude přesně pro vás. Pokud by vás něco zaujalo, termíny najdete zde.

Inspirativní může být i návštěva konference, kterých je po světě hodně. Za zmínku určitě stojí Global Scrum Gathering, který bude v Londýně na podzim 2018, což je kousek, a pak samozřejmě moje nejoblíbenější Agile Prague 2018 (10.-11. září 2018), která je ještě blíž 🙂 .

Tolik mých pár Vánočních tipů z našeho nejbližšího okolí.

Dnešní změna Scrum Guidu

Dnes proběhla další z dlouho očekávaných změn Scrum Guidu – tedy popisu Scrumu, který všechny kvalitní Scrum certifikační organizace společně uznávají jako základní dokument definující Scrum. Tak se pojďme podívat na změny, které tento update přinesl. Tak v první řadě dobrá zpráva je, že Scrum jako takový se mění v podstatě jen drobně. Většina změn cílí na lepší vysvětlení toho, co je Scrum a kde se používá, případně napravuje nejčastější chyby jeho pochopení.

Nově Scrum Guide definuje kontexty, kde se Scrum používá, což je zajímavý krok k tomu zbavit se nálepky “Jen pro geeky“ a ukazuje výrazný posun k “Jsme tu pro všechny činnosti, které děláte“, což je dlouhodobý trend, který je na Agile a Scrum v posledních pár letech viditelný. Pár příkladů kontextů, kde Scrum Můžete použít:

  • Research a identifikace trhu, produktu a funkcionality (tedy Scrum jde použít na věci o kterých ještě nevíme, co jsou zač a jak mají vypadat a chceme to zjistit),
  • Vývoj produktů a jejich vylepšení (tedy vytvoření něčeho o čem víme, jak má vypadat),
  • Release produktů a jejich zlepšení i několikrát denně (tedy dodávání klidně i v módu Continuous Delivery),
  • Vývoj a údržba Cloudů a jiných podobných prostředí (tedy operations a v podstatě vše co se skrývá pod buzzwordem DevOps),
  • Sustaining, maintanance a podobně.

A dodává výčet prostředí v dnes tolik skloňovaném “Scrum mimo IT” jako je například hardware, embedded software, síťová řešení, autonomní řízení, školství, státní instituce, marketing, řízení organizací a vlastně vše, co děláme v našem běžném životě.

Jako další bod nový Scrum Guide explicitněji vysvětluje ScrumMastera jako servant leadera, který se podílí na transformaci celé organizace, což je příjemná změna, která je naprosto v souladu s tím, jak roli vysvětluji na kurzech a ve své knize The Great ScrumMaster: #ScrumMasterWay.

Ale to asi nejlepší ze všech změn je, že jsme se konečně zbavili “těch třech otázek“ co všichni měli na každém Daily Scrum meetingu zvaném Standup správně používat. Co mi to vždy dalo práce lidem vysvětlit, že standup tu není kvůli hlídání individuálnímu statusu jednotlivců ani micro-managementu, ale abychom si domluvili, co budeme jako tým dělat, abychom dosáhli cíle Sprintu (Sprint Goal). Tři otázky nezmizely úplně, tedy nemusíte se bát, že jste doposud dělali všechno špatně, jen se staly jedním z doporučení jak Daily Scrum  dělat.

Jediné, co vnímám jako zvláštně nekoncepční změnu (tedy něco co odporuje trendu, že Scrum nedefinuje praktiky JAK věci máte dělat, ale CÍL kterého máte dosáhnout) je to, že Sprint Backlog má obsahovat Action steps z Retrospektivy. Chápu, že to některým týmům může pomoci, ale proč to nemáme jen jako doporučení v sekci o Retrospektivě, mi není úplně jasné. Ale třeba to časem nějak vstřebám. Ostatně, třeba to pomůže Sprint Backlogu, který po minulé změně posilující důležitost Sprint Goalu na úkor Sprint Backlogu ztratil na důležitosti, a touhle změnou zase získá zpět svůj význam.

Suma sumárum je to dobrá sada změn a přestože některé věci, které bych ráda viděla jinak, zůstávají, je Scrum Guide dobrou definicí Scrumu, která se tímto updatem stala ještě o trošinku lepší.