Agile | Zuzi's Blog o Agilu a Scrumu

Jak hledat Product Ownera

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

Znalost 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 collaboration Jeden 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).

Jak na Open Space – část 5

V předchozích příspěvcích jsem se věnovala tématům co je to Open Space, jak začít a skončit, jaké má role, a kde všude by se dal formát Open Space použít. Tak se teď pojďme podívat, jak začít. Nebát se. To, co z Open Space vzejde, ještě není nutně to, co se musí přesně takhle implementovat. Je to jen začátek, co jedna skupina navrhuje. K implementaci ještě vede dlouhá cesta, kdy je třeba o nápadu přesvědčit ostatní. Tedy, nemusí být až tak dlouhá, ale to, co jsem chtěla zdůraznit je to, že co skupina lidí navrhne, není automaticky rozhodnutí. Někdy trvá následná změna jednotky minut, kdy se všech na konci zeptáte na to jak to vidí a když všichni souhlasí, změnu uděláte. Někdy finální implementace trvá měsíce, protože nápad musí projít právníci, finance, či jiná oddělení a domyslet konkrétní podobu. A někdy se nápad nikdy nestane, protože se neukáže z pohledu organizace jako praktický. I to se může stát.

OpenSpace

Je to formát, který staví na kreativitě a dívá se na věci jinak, takže z něj často vzniknou zajímavé návrhy, které by standardně nikoho nenapadly. Je to formát postavený na dobrovolnosti, takže má nadšené lidi již od začátku a nemusí se potýkat s demotivací. Je to formát, který staví na diversitě a umožňuje lidem zaměřit se na tu část problému, která jim připadá nejzajímavější a tu společně zkusit o kousek posunout. Pravidla jsou pro lidi s agilním mindsetem jednoduchá a ničím neobvyklá. V agilní organizaci se nad takovým stylem práce nikdo nepozastaví a workshop poběží v podstatě sám. V tradiční organizaci, kde mají lidé pořád pocit, že na to, aby se něco stalo, musíte mít reporting a centrální řízení, vzbudí obvykle takový formát pozdvižení a někdo z managementu ho radši ‘včas’ zastaví. Ještě by zaměstnanci vymysleli něco, co my nechceme a co pak? Je lepší je k ničemu nepustit. Takže přestože je facilitace jednoduchá a workshop samotný nemůže špatně skončit, na některé organizace a managery působí jako červený hadr na býka. Je to ve finále advanced technika agilního světa. Možná podle reakce na takový Open Space poznáte, jestli jste agilní nebo zase až tak moc ne. Představte si podobnou konverzaci ve vaší organizaci:

„Chtěli bychom zorganizovat půldenní workshop na téma, jak zlepšit [xxx]. [xxx] je náš největší problém, stojí nás měsíčně [yyy] času/peněz a zatím se nám ho nedaří zlepšit. Chtěli bychom pozvat všechny členy týmů, aby se společně v rámci Open Space zamysleli, co bychom s tím mohli udělat.“

Jaká asi bude reakce vašeho okolí?

[0]: „Žádné změna v této oblasti nepřipadá v úvahu. Stačí když budete dělat to co máte (je v procesech).“

[1]: „Kolik to bude stát? Nemůžeme tomu věnovat půl den, musíme pracovat na dodávce.“

[2]: „Nemůžete přeci pozvat všechny. Jestli se tomu opravdu chcete věnovat, udělejte malou skupinku a té to dejte na starosti.“

[3]: „Opravdu je účast dobrovolná? A co když …?“

[4]: „Dejte mi vědět, jak to dopadlo.“

[5]: „Můžu také přijít?“

Je to jednoduchý test. Počet bodů, které jste v průměru získali ukazuje nakolik agilní jako organizace jste.

Nula znamená, že vaše organizace na podobné agilní praktiky není ready a je hluboko v tradičním mindsetu. Začala bych s něčím menším, na čem organizaci ukážete že selforganizace a decentralizovaný styl práce funguje.

Trojka vám dává šanci to zkusit, ale budete muset hodně vysvětlovat a ujišťovat. Když se vám první takový workshop povede prodat v rámci organizace, máte většinou vyhráno a čas od času takový nástroj můžete použít.

Pětka je znamením, že jste na vaší agilní cestě došli tak daleko, že už se nad Agilem nikdo nepozastavuje a přešel vám do krve. Agile je to co nejen děláte, ale žijete. Open Space workshopy se stanou běžnou součástí vašeho firemního života a začnou je organizovat i ostatní lidé v rámci firmy, kdykoli budou řešit problém, kde je potřeba kreativita a zapojení větší skupiny lidí.

Kde se dá použít Open Space – část 4

V předchozích příspěvcích jsem se věnovala tématům co je to Open Space, jaké má role a jak by se měl takový Open Space workshop začít a skončit. Pojďme se tedy podívat, kde byste tento formát mohli použít. Open Space se často používá na konferencích (např. Agile Prague Conference ho již několik let intenzivně využívá), aby posunuli zážitek z přednášek a workshopů do konkrétní roviny a dali tak prostor každému prodiskutovat jeho konkrétní problém, nebo se nechat inspirovat tím, co zajímá ostatní. Asi největší skupina, kterou jsem viděla, bylo cca 1200 lidí, běžně se obzvláště ve firmách, které takový formát využívají pravidelně, účastní něco kolem stovky lidí. Ale počet lidí tady není limitem. O konferencích, kde je takový formát běžný, teď ale mluvit nechci. Takže kde jinde se tento formát používá? V podstatě kdekoli, kde jsme ready na opravdovou samoorganizaci a potřebujeme dát dohromady větší skupinu lidí. Je to nástroj, který staví na takzvaném emergent leadershipu, tedy tomu, že když vás něco zajímá, tak se za to postavíte, převezmete zodpovědnost a zkusíte kolem sebe zformovat skupinu lidí, které dané téma také zajímá. V Agilní organizaci se používá poměrně často. Na inovace, řešení konkrétních problémů, jako například jak změnit systém ohodnocování, jak by měly vypadat nové prostory, jak zlepšit kvalitu, přístup k zákazníkům, nebo třeba jako forma Backlog Refinementu nebo celofiremní Retrospektivy.

OpenSpace

Poprvé jsem se ho účastnila kdysi dávno, někdy v roce 2003, kdy naši zákazníci chtěli změnit styl práce. Bylo to ještě pár let před Agilem, prostě jen chtěli investovat sto dní do lepšího stylu práce. Jmenovalo se to 100 dní improvementů, kdy týmy po dobu 100 dní pracovaly na zlepšení procesů, infrastruktury, automatizaci apod. A úplně první byl Open Space, kde jsme všichni brainstormovali, co by nám mohlo v dalším vývoji produktů pomoci, a jak bychom mohli nejlépe investovat výše zmíněných sto dní do improvementů tak, aby se nám to vrátilo. Pár let na to jsem pomocí formátu Open Space facilitovala workshopy na celkovou změnu HR, zlepšení development nástrojů, co udělat pro růst lidí a redesign prostor. Jedním z mých oblíbených workshopů facilitovaných formátem Open Space je overal retrospektiva, kde týmy, které spolupracují na jednom produktu, takto v menších skupinkách vymyslí, jak by mohly zlepšit spolupráci mezi týmy.

Začátek a konec Open Space – část 3

V předchozích příspěvcích jsem se věnovala tomu, co je to Open Space a jaké role obsahuje. Teď se na něj podíváme prakticky. Co potřebujete? Velkou místnost, kde bude probíhat takzvaný marketplace, tedy tržiště nápadů. Jak to vypadá? Většinou máte židle v kruhu, pro větší skupiny klidně i v několika řadách, uprostřed stojí facilitátor, který Open Space uvádí. Vysvětlí, jaké jsou pravidla a principy, připomene ještě jednou téma celého Open Space a otevře tržiště nápadů. Účastníci potom jeden po druhém představí ostatním oblast, které se chtějí věnovat, napíšou ji i se svým jménem na papír a ten přiřadí na tabuli konkrétnímu místu a času.

OpenSpace

Někdy se vlastníci oblastí domluví na jejich sdružení, protože jsou to podobná témata, a někdy ještě na poslední chvíli změní čas, aby se mohli zúčastnit konverzace o jiné zajímavé oblasti. Ten, kdo téma nadhodil, může přijít s vlastním nápadem, nebo jen facilitovat diskusi mezi účastníky a nechat nápady na nich. Formě se meze nekladou. Každé místo má flipchart, aby účastníci mohli zaznamenat podstatné body konverzace pro ostatní a výstupy konverzace nezapadly. Na konci se znovu všichni sejdou a za každou skupinu odprezentují ostatním, k jakým výstupům došli.

Open Space bývá většinou vstupem dalším aktivitám či workshopům. Open Space to většinou nekončí.

V dalších příspěvcích se podíváme na to, kde se dá Open Space použít, a jak na na to.

Role Open Space – část 2

Lidé jsou různí. A takhle otevřený formát, jako je Open Space, potřebuje různorodost vstřebat a akceptovat jako hlavní princip. Jak již jsme řekli, cokoliv se děje, je ta správná věc, která se dít má. Co tedy můžete v rámci Open Space dělat? Nebo chcete-li, jaké Open Space definuje role? Tak kromě facilitátora neboli hostitele Open Space, a těch co se účastní konkrétní diskuse v kroužku účastníků, můžete použít “law of two feet”, tedy kdykoli máte pocit, že vám diskuse až tak moc nepřináší, nebo že potřebujete chvilku času strávit co se děje, tak se seberete a jdete jinam. A právě proto Open Space definuje dvě role: “Bumble Bee” a “Butterfly” tedy Čmeláky a Motýly.

Čmelák (“BumbleBee”)

Čmeláci volně poletují od jedné skupinky ke druhé. Vždy si poslechnou si kus konverzace, a pak zas přeskočí k další skupince a konverzaci. Často se stane že inspiraci, kterou získali v jedné skupince přenesou do jiné a tím vlastně dělají takový most mezi konverzacemi.

Open Space

Motýl (“Butterfly”)

Druhou rolí, která není plným účastníkem konkrétní konverzace je motýl. Motýli poletují kolem. Občas něco zaslechnou, a potřebují si nápady nechat uzrát v hlavě, a tak se posadí někam bokem aktivních konverzací a využijí daný čas na reflexi. Občas se stane, že si další motýli přisednou a vznikne tak zcela neplánovaná skupinka na aktuální téma. Nebraňte se.“Kdykoliv to začne, je ten správný čas“, “Kdokoli přijde, je ten správný účastník“ a hlavně “Co se stane, je jediné, co se mohlo stát“.

Open Space

Open Space vás k ničemu nenutí. Je to naprosto volný formát. Tak se nebojte, a buďte sami sebou. Uvidíte, že se vám Open Space bude líbit. 🙂

Facilitace velkých workshopů: Open Space – část 1

V poslední době jsem několikrát zmiňovala formát Open Space (Open Space Technology – OST). Překvapivě ani zkušení agilisté ho často neznají. Pojďme se tedy podívat, co to vlastně Open Space je. Open Space formát je facilitační technika, která umožňuje zapojit kreativitu systému a umožnit velké skupině lidí distribuovaně pracovat na společném tématu. Využívá samoorganizace a dává lidem prostor, aby si sami vybrali konkrétní body, kterým se budou věnovat.

Open Space

Zní to komplikovaně, ale není na tom nic složitého. Open Space formát má jen jedno poměrně jasné pravidlo a čtyři hodně filosofické principy. Pamatuji si, že mě na začátku dost odrazovaly. Jsou psané takovým zvláštním jazykem, prostě moc komplikovaně napsané. 🙂 Ale v podstatě popisují samoorganizaci. Takže v momentě, kdy jsem přestala přemýšlet o principech, začal se mi Open Space líbit a šlo to vlastně samo.

“Law of Two Feet“

Pravidlo je takzvané “Law of Two Feet “, tedy takzvaně zákon dvou nohou, které každému umožňuje převzít zodpovědnost za to, co ho zajímá a v případě, že se octne v konverzaci kde se ani nic nového nedozvídá, ani sám ničím nepřispívá, musí použít svých nohou a odejít na nějaké jiné místo, kde bude konverzace pro něj přínosnější. To je asi klíčem úspěchu Open Space. Jen si představte, že byste tohle pravidlo používali v práci každý den. Na kolika meetingách byste zůstali? A o kolik zajímavější by byly konverzace, kterých byste se účastnili, protože by vám na ně najednou zbylo spousta času? Pravidlo vlastně definuje účast jako dobrovolnou. Každý se může zúčastnit, a každý může odejít, když mu účast už nic nepřináší.

OpenSpace - Law of Two Feet

Pravidlo je základ, principy potom pomáhají účastníkům se v Open Space prostoru pohybovat a vlastně definují samoorganizaci účastníků:

“Kdokoli přijde, je ten správný účastník“

Kdokoliv, koho konverzace zajímá, je tím nejlepším účastníkem. Účast je tedy otevřená naprosto všem. Nemůžete ji nijak omezit, a to ani počtem, ani zkušenostmi či znalostmi. Open Space musí být otevřený všem a neklást účasti žádná omezení.

“Co se stane, je jediné, co se mohlo stát“

Nepřemýšlejte, co by se stalo kdyby. Konverzace běží směrem, kterým běží. Přišli ti, co přišli. To, co se děje právě teď, je to jediné, co se dít má. V podstatě by se dalo říct, že jsme všichni do jisté míry ovlivněni svými zkušenostmi, představami a plány, které nás neustále nutí přemýšlet o minulosti nebo budoucnosti. Tento princip nás vrací do současnosti, kde nehodnotíme, co by se mohlo stát, ale plně se soustřeďujeme na to, co se děje právě teď, v přítomnosti.

“Kdykoliv to začne, je ten správný čas“

Tvůrčí duch nejde naplánovat a naším úkolem je nebránit toku kreativity. Kdykoli začne, je to ten správný čas. A jestli to znamená, že potřebujete pokračovat déle, než jste plánovali, pokračujte v konverzaci. A jestli to znamená, že začnete až později, nic se neděje.

“Kdykoliv to skončí, je konec“

Kreativita má svůj vlastní rytmus, zaměřte se na něj a věnujte mu pozornost. Čas není pro skončení konverzace až tak důležitý. Když máte pocit, že by bylo dobré téma ukončit, zeptejte se skupiny. Když souhlasí, přejděte k další věci, která vás zajímá a láká ke konverzaci, když ne, pokračujte.

Jak vidíte, není na tom nic složitého. Ale asi toho už je pro dnešek dost. V dalších příspěvcích se podíváme na to, jak Open Space začít a skončit, kde se dá Open Space použít, a jak na na to.`

Mini kniha Agilní HR – Jak změnit Human Resources v agilní organizaci

Agile HR Nedávno jsem napsala několik blogů na téma Agilního HR, které měly velice dobrou odezvu. Spousta lidi se ptala, evidentně je to téma, které lidi dneska zajímá. A to mě nakonec přimělo příspěvky zkompilovat do většího celku, trochu je uspořádat a dopsat pár dalších kousků, aby vše dávalo pohromadě smysl. A tak vznikla malá publikace „Agilní HR aneb Jak změnit Human Resources v agilní organizaci“, která je zdarma ke stažení na stránkách Leanpub.

Agile je dnes velmi skloňovaný pojem, a to nejen v rámci IT. Aby se organizace opravdu stala agilní, je potřeba, aby i HR fungovalo na stejné vlně. Navíc agilní HR je u nás stále ještě docela opomíjené téma, a to byla i část motivace, proč jsem takovou knihu chtěla sepsat. Navíc tématu Agilního HR se u nás nikdo konzistentně nevěnuje, a tak vidíte ve firmách spoustu paskvilů, které nejenže Agilní transformaci nepomáhají, ale naopak jí často škodí. Nečekám, že vše, co v knize píšu, budete hned aplikovat. Spousta věcí je inspirací pro příští roky. Ale mělo by vám to ukázat, jakým směrem se ubírat v oblasti nabírání lidí, ohodnocování, rozvoji zaměstnanců, systému a struktuře pozic a kariérního řádu. Zkratky neexistují a pokud realizujete změnu firemní kultury a myslíte to s Agilitou vážně, i HR se musí změnit více než kosmeticky.

sochova.com AgileHR Book Touhle mini knihou jsem chtěla popsat takový malý základ, jak s Agilním HR začít a o čem to celé je. Snad to bude přínosné. Je ke stažení zdarma, ale Leanpub umožňuje autorům udělat takový malý sociální experiment, a umožnit kupujícím si cenu zvolit. Takže tady je deal, když pár lidí zaplatí, budu to brát jako potvrzení, že lidi téma zajímá a že si ho cení a dopíšu další kapitolu 🙂 Ty následující se týkají dalších sekcí v kapitole Tipy, Praktiky, Doporučení. Ať tak či tak, dejte vědět, co by vás ještě zajímalo a o co mám případně knihu v příští verzi rozšířit. Je to taková agilní kniha psaná agilně. Když je dobrý feedback, kniha se bude rozšiřovat. Když není feedback žádný, zůstane zapomenuta jako pěkný experiment 🙂

Stáhněte si knihu a začněte číst. Doporučte ji svému HR. Doufám, že se vám bude líbit.

A kdybyste si na dané téma chtěli poslechnout přednášku, můj talk HR Goes Agile bude k vidění namátkou třeba na Agile2019 ve Washingtonu, Agile Prague a Agile Austria v Grazu kde můžete přijít i na jednodenní stejnojmenný workshop.

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.

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