Facilitace velkých workshopů: World Café

World Café je dalším formátem, který můžete použít při facilitaci větších workshopů v agilní organizaci. Je to skvělý nástroj pro škálování konverzace a využití kreativity systému. Staví na principech self-organizace a cross-functionality, tedy nic, co by v agilní organizaci bylo neobvyklé. V podstatě na tom nic není. Lidé sedí v malých skupinkách kolem stolů, jako v kavárně, odtud ostatně máme ten název, a diskutují o tématu. K dispozici je obvykle spousta barevných fixek, post-its a flipchart, aby účastníci mohli zajímavé body z diskuze zapsat, nebo nakreslit. Po každém kole diskuse se účastníci náhodně zamíchají do nových týmů a pokračují v konverzaci.

World Café začíná vysvětlením celého formátu. Potom facilitátor připomene očekávání od konkrétního World Café workshopu, aby všichni věděli, co je cílem. World Café je skvělý nástroj k popsání možností řešení nějakého komplexního problému, který zahrnuje hodně týmů.  Poprvé jsem se World Café účastnila na XP2011, kde jsme jako zástupci agilních komunit hledali vizi ALE – Agile Lean Europe network, později jsem tento formát využila mnohokrát ve velkých firmách, abychom si udělali představu o procesech, které se v reálu používají, a jak se liší od těch oficiálních popsaných, co chceme od nových prostor v organizaci, nebo jak zlepšit mezi-týmovou spolupráci. Nejde ani tak o nástroj pro rychlé rozhodování, ale pomáhá velkým a různorodým skupinám přemýšlet o současném stavu, naslouchat hlasům systému a získat povědomí o tom, jaké jsou různé perspektivy. A to se hodí v podstatě kdekoliv.

World Cafe

Na začátku poprosíme účastníky, aby vytvořili co nejrůznorodější týmy s různými rolemi, zkušenostmi a znalostmi, aby pokryly co nejvíce perspektiv. Obvykle se diskuse vede ve třech (nebo více) 20-ti minutových konverzacích na dané téma, kde každé kolo konverzace ovlivňuje otázka. Otázky se netýkají tří různých témat, ale místo toho se dívají na stejné téma ze tří různých úhlů, aby pomohly lidem prozkoumat danou oblast z různých perspektiv a zapojit kreativitu celého systému. V každém kole skupinka vybere jednoho člověka, který ve skupině zůstane, a vysvětlí na začátku dalšího kola novým účastníkům podstatu předchozí konverzace. Užitečným artefaktem je vizuální facilitace na flipchartu. Zbytek lidí si náhodně zvolí jiný stůl pro konverzaci, přičemž má na paměti rozmanitost a cross-funkcionalitu skupin. Na konci posledního kola všechny skupiny prezentují své výsledky ostatním a vyvěsí summary na flipchartech, aby bylo vidět k čemu došli. Tady World Café končí. Cílem není věci vyřešit, ale zvýšit transparentnost o dané situaci či oblasti. Jako follow-up můžete pokračovat jakoukoli facilitační technikou konvergující k výběru řešení nebo akčních kroků, ale to už je nový workshop.

Jak hledat Product Ownera

Dobrý Product Owner by měl mít znalost businessu, autoritu a čas.

Product OwnerZnalost businessu je něco víc než znalost produktu a jeho funkcí. Na to často stačí dobře fungující development tým. Je to i pochopení celého segmentu zákazníků, jak se business chová, co na trhu chybí a po čem je poptávka.

Autorita je potřeba, aby se Product Owner dokázal dobře rozhodnout, co udělat teď a co později, nebo nikdy, tedy prioritizovat na základě business hodnoty. Product Owner musí umět říct “ne“.

Čas je nutný nejen vzhledem k zákazníkům a businessu, ale i development týmu. Dobrý Product Owner je součástí týmu a spolu s development týmem a zákazníkem (interní stakeholdeři, uživatelé, … ) spolupracuje na porozumění backlogu. Product Owner není tichá pošta mezi týmem a zákazníky, ani ten kdo píše všechny položky backlogu/User Story. To se vše děje společně na Backlog Refinementu. Product Owner tedy musí být dobrý v komunikaci, umět vyjednávat, a facilitovat větší workshopy (Refinement) a umět věci jasně vysvětlit a komunikovat.

Znalosti by měl mít alespoň na úrovni na úrovni certifikací CSPO – Certified Scrum Product Owner (případně CSM – Certified ScrumMaster jako doplněk pro hlubší pochopení Scrumu.

Zkušenost ze Scrum prostředí: Dobrý Product Owner by měl zažít pravý Scrum na úrovni celého produktu, zkušenosti ověřené certifikací A-CSPO – Advanced Certified Scrum Product Owner, nebo v lepším případě CSP-PO – Certified Scrum Professional – Product Owner).

Alespoň základy (a plánuje se rozvíjet v daných oblastech): Vyjednávání, komunikace, facilitace, schopnost naslouchat, leadership skills.

Dobrý Product Owner by měl být schopen efektivně spolupracovat v rámci týmu.

Když se nad tím zamyslíte, dobrý Product Owner se daleko snáz hledá interně, než najímá externě, ostatně je to někdo, kdo má na starosti celkový úspěch businessu, takže je lepší vzít někoho koho znáte a víte, že ve vašem businessu dobře orientuje. Product Ownerů navíc nepotřebujete tolik, na jeden produkt (i ten větší) stačí jeden Product Owner. Ostatně není na to sám, pomáhají mu v rámci Backlog Refinementu development týmy.

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

Agile Prague Conference 2019

Jako každý rok, chystáme v září konferenci Agile Prague. Tentokrát již devátý ročník. Agile Prague je každoročně největší událostí Agilního světa u nás a stejně jako poslední roky má bohatý program. Takže na co se můžete těšit?

Tématem letošního roku je Agile journey, tedy takzvaně cesta k agilitě. Agile již dávno není jen doménou IT, ale používá se v rámci celé organizace a taková změna je určitě náročná. Agile je cesta. Cesta plná změn, cesta, která pomáhá firmám se adaptovat na problémy dnešního světa.

Každý den začínáme dvěma keynotes, dále pak program kombinuje krátké 30 min talky, odpolední workshopy a praktické case-studies.

Agile Prague Conference 2019

Jako již tradičně poledne není jen čas oběda, ale i možnost zapojit se do openspace, kde program vzniká na místě a kdokoli z vás může nabídnout jakékoli téma o které se chce podělit nebo se o něm něco dozvědět. Věnovat se budeme velkým transformacím, leadershipu, modernímu managementu, kultuře týmů, produktům a scalingu, agilitě na úrovni organizace. Nechte se inspirovat.

Po oba dva dny zároveň běží Coaches Clinic, tedy místo, kde vám zkušení koučové poradí s čímkoli budete potřebovat.

Z programu namátkou zmíním Pete Behrens, který stojí za vznikem Certified Agile Leadership programu a na konferenci se s vámi podělí o své zkušenosti s agilními transformacemi, Ralph van Roosmalen, který se podělí o své zkušenosti jako CEO velice agilní organizace Happy Melly, a Heidi Helfand která se zaměří na změny v týmech, z Nového Zélanndu přijede Samantha Laing s tématem osobnostního rozvoje, Jurgen De Smet se zaměří na podstatu Scrumu a rozebery kdy Scrum má a nemá smysl nasazovat (mimochodem, Jurgen je specialista a trenér na LeSS, který v listopadu opět přijede do Prahy realizovat certifikačni LeSS workshop). A mnoho dalších. Ostatně posuďte sami a podívejte se na program konference.

Jako obvykle je konference doplněna workshopem na témaDesign Thinking: Human-Centred Design in Agile,kde vás Stuart Young provede customer centric designem produktu.

Myslím, že se je na co těšit. Doufám, že se tam v září potkáme🙂

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.

Na které věci můžete v Agilním prostředí zapomenout

Specifikace

Specifikace v takovém tom klasickém slova smyslu je mrtvá. Agilní prostředí se daleko více zajímá o to co je to minimum, které musíme implementovat abychom dodali maximum business value, než co všechno musíme naimplementovat abychom se do nějaké té business hodnoty trefili. Jak říkal jeden můj známý ScrumMaster, klasické organizace často se zavázanýma očima střílí na kachny. A protože střílí hodně, občas nějakou trefí. Agilní organizace pochopily, že méně je někdy více, a přestali trávit hodiny času specifikací toho co všechno bychom taky mohli udělat. Na místo toho se v rámci Inspect and Adapt principu a časté zpětné vazby snaží pochopit co přináší nejvyšší business hodnotu a na tu se soustředí. Ano, je to změna, a bude to těžké, ale o tom Agile právě je.

Častým nepochopením je že organizace mají pocit, že v rámci UserStory musí psát detailní popis, jak danou potřebu adresovat například formou Akceptačních kritérií. To ale vůbec nepatří do UserStory. Ta by měla pouze definovat potřebu konkrétního uživatele/persony, ‘jak’ji budeme řešit je na dohodě týmu v rámci Sprintu. Ano, pre-rekvizitou je pochopení toho co děláme celým týmem, tedy dobrý Product Owner a Backlog Refinement. Jinak vám ale Scrum ani Agile fungovat nebude. Agile i Scrum je customer centric, business driven. Takže zapomeňte na specifikaci, zkuste se zcítit do zákazníků a pochopte jejich potřeby. Jen tak dosáhnete lepších výsledků.

Projekty

Další věcí, která se dříve či později octne na smetišti dějin, jsou projekty. Stejně jako role project managera. Ale o tom třeba zase příště. Projekt je totiž jen kontejner, v jehož rámci řídíme a zpracováváme práci v klasickém světě. V agilním světě nám stejnou službu dělá Product Backlog, jeho položky a krátké Sprinty/iterace se zpětnou vazbou. Product Backlog je navíc daleko lépe optimalizovaný na vysokou adaptivnost systému, reakce na změny a obecně práci v komplexním prostředí. A tak důležitost světa produktů postupně uvadá. Že jste projektovými managery? Určitě se pro vás najde uplatnění. Project manageři se nejčastěji stávají stakeholdery, kteří pomáhají týmům pochopit kontext zákazníků, častá bývá i změna na Product Ownera, výjimečně ScrumMastera. Většinou platí, že když jste byli potřeba v předchozí neagilní struktuře, budete potřeba i v té nové. Jen vaše role a práce se změní. Ale to platí nejen pro projektové managery, ale i developery, testery, analytiky, a managery. V agilním světě je všechno jinak a jednoduchý mapping neexistuje. Agile je změna mindsetu, a ta začíná ve vaší hlavě. 🙂

Tribe firmu agilní neudělá

Všechny české organizace asi v poslední době napadl virus ‘fake Agile & Scrum’. Jak se virus pozná? Přesvědčil jinak docela rozumně uvažující organizace, že když department přejmenují na tribe, bude všechno lepší. Inspiraci jde asi hledat ve Spotify (která se sama svým “modelem“, co nikdy model nebyl, neřídí), nebo v holandské ING, která terminologii v rámci své transformace použila a znovu zpropagovala. Obě zmiňované case-study mají jedno společné. Obě organizace prošly zásadní transformací hodnot, přístupu, kultury. Ti, co je slepě aplikují však nejdou cestou změny mindsetu, ale přelabelováním existujícího. Nové šaty ale člověka samy o sobě nezmění. A tak tyto organizace docela bolestivě failují. Jedna nejmenovaná korporace, co přešla na ‘Spotify model’ po roce musela v podstatě zahodit všechno co udělala a vrátit se v produktech o rok zpět.

Však ono těm organizacím o žádnou změnu ani nejde. Stejně jako u SAFe se jen snažíme chytře umožnit firmám, aby si odškrtli agile jako ‘done‘, a nemuseli se měnit. SAFe na to jde chytře a generuje tisíce naprosto nesmyslných rolí a názvů jako train, release train engineer a pak jakási ‘kolečka‘, asi od toho vlaku :). Naopak ‘Triby‘ jsou tu pro ty co jsou cool a nějaké vlaky jim přijdou v 21. století trochu nemoderní. Ale vyjde to nastejno. Škoda. Jedna velká americká organizace nedávno začala svou v pořadí třináctou Agilní transformaci. Nojo, fakt. Prý se jim to tentokrát už možná povede. Už pochopili, že Agile není jen o terminologii, ale je to změna myšlení, přístupu, mindsetu. Tak jestli se vás tento virus ‘fake Agile & Scrum’ týká, nesmutněte. Ještě tak 5 pokusů a ono to vyjde. Není to těžké, chce to jen přestat předstírat, že se měnit nemusíte a pohlédnout pravdě do očí :).

Dobrá zpráva je, že v zahraničí už “Spotify model” nefrčí. Když jsem to zmínila na Agile2018 v SanDiegu, všichni se divili proč by to kdo kopíroval. Takže ta dobrá zpráva je, že tato móda přejde, stejně jako móda džínů do zvonu. Občas se vrátí, ale už nikdy to nebude hýbat světem. Takže stačí počkat a možná za pár let budeme opravdu řešit otázky, které jsou strategické a mají smysl. Hodně mě překvapilo kam se konference posunula of roku 2012, kdy jsem tam mluvila naposledy. K lepšímu. Takže když příští rok budete chtít vidět co se opravdu děje v Agilním světě, Agile Alliance Agile 2019 je to správné místo. Jen musíte trochu našetřit do kasičky 🙂

Nejčastější nepochopení Scrumu

Scrum je velmi jednoduchý framework. Bohužel ale není vůbec snadný aplikovat. Je to velká změna myšlení, přístupu, hodnot. Když se půjdete do běžné firmy podívat, tohle asi budou nejčastější nedorozumění, a nepochopení, na které narazíte:

Scrum

Daily Scrum jako status meeting

Daily Scrum alias Standup meeting je tak triviální věc, že by jeden řekl že se snad ani nedá zkazit. Chyba lávky. 80% firem ho bere jako status meeting, kde každý jednotlivec referuje (managerovi, ScrumMasterovi, nebo ostatním členům týmu) co dělal. A kosmetické změny ScrumGuidu, které se snaží vysvětlit, že je to celé o synchronizaci týmu, jejich diskusi, jak dosáhnou cíle Sprintu (Sprint Goal), zůstávají bez povšimnutí. Kde jinde bychom ty líné vývojáře kontrolovali a řídili, vždyť jinak nebudou nic dělat.

“Cílem Daily Scrumu je synchronizace členů týmu a jejich dohoda, jak budou dále pracovat na dosáhnutí cíle Sprintu, tedy Sprint Goalu.“

Sprint Backlog se nesmí měnit, je klíčový

Když už jsem zmínila Sprint Goal, pojďme u něj zůstat. Většina firem žádné Sprint Goaly nepoužívá. Vystačí si se Sprint Backlogem, který navíc mylně vnímá jako neměnnou specifikaci, která do detailu popisuje, co přesně má tým (rozuměj ‘coding monkeys‘) naimplementovat. Sprint Backlog je ale jen rámcovou dohodou, jak chceme dosáhnout cíle Sprintu. Klíčovým artefaktem je Sprint Goal, který definuje, čeho z pohledu business value chceme dosáhnout. Ten by se měnit neměl, protože to je to do čeho v rámci Sprintu investujete. Sprint Backlog se naopak v závislosti na situaci a dohodě týmu klidně měnit může. V podstatě s tím, jak se ve Scrumu začal Sprint Goal více používat, přestal být Sprint Backlog téměř potřeba, natož aby byl neměnný.

“Sprint Goal definuje smysl Sprintu, čeho chceme z pohledu business value dosáhnout. Sprint Backlog nám pouze pomáhá udělat dohodu ‘jak’ toho chceme dosáhnout. “

Sprint Review je o akceptaci

A do třetice všeho dobrého, nebo spíš zlého :), takové běžné Sprint Review alias Demo velmi často skončí jako prezentace technických scénářů Product Ownerovi. Proč prezentujeme něco někomu, kdo měl být celou dobu přitom, je mi záhadou. Někde prezentujeme Product Ownerovi proto, že nikoho jiného technické scénáře nezajímají, jinde protože se bojíme členy týmu komukoli ukázat, aby neudělali ostudu, jinde ani Product Owner nechodí a děláme to jen protože Scrum. Sprint Review je klíčovým prvkem Scrumu, protože právě tady získáváme zpětnou vazbu na doručený Sprint Goal, tedy funkční inkrement produktu, nebo jinak řečeno dodanou business hodnotu. Jdeme správným směrem? Je tohle opravdu business hodnota? Dosáhli jsme očekávaného impactu? To jsou otázky, které je dobré si v rámci Sprint Review položit.

“Cílem Sprint Review je získat zpětnou vazbu od zákazníků, stakeholderů, uživatelů abyste se na jejím základě mohli adaptovat. Je to klíčovým prvkem a by vám fungoval proncip Inspect and Adapt.“

 

Jestli jste se ve výše zmíněných příkladech nepoznali, dobrá zpráva. Asi jste se už vymanili z područí ‘Technického Scrumu’, nebo ’Dark Scrumu’ a jste o krok blíže změně mindsetu. Jen tak dál 🙂