Z projekťáka ScrumMasterem

Spousta lidí si myslí, že Project Manageři jsou dobrými kandidáty na ScrumMastery. Ze zkušenosti tomu tak ale ne vždy je. Většina projekťáků má s přechodem na roli SrumMastera velké potíže. Je to hlavně o hodnotách a o tom, co považujete za důležité.

Asi největším rozdílem je, že ScrumMaster není zodpovědný za dodávku v rámci Sprintu, za kterou je zodpovědný Development tým, ani za dodávku produktu jako takového, za kterou je zodpovědný Product Owner, ale za to, aby tým dobře fungoval, zlepšoval se a byl takzvaně self-organized, tedy samoorganizovaný. A to vyžaduje úplně jiný přístup, než organizace práce na projektu. Je to o coachingu, facilitaci, nadšení a víře, že Agile a Scrum funguje a je tou správnou cestou, schopnosti měnit kulturu organizace a stavět dobře fungující týmy. Převážně jde o softskilly.

Dalším rozdílem je, že v agilním světě nejsou projekty. Ostatně není pro ně důvod. Dodávku řídíme pomocí Product backlogu, kde Product Owner položky backlogu prioritizuje, podle business value.

A posledním rozdílem je, že nám až tak nejde o efektivitu. Dodání více funkcionality zdaleka totiž neznamená že dodáte více hodnoty. Scrum je Business value-driven, customer-centric. Maximalizujeme hodnotu za minimalizace effortu. Estimaty, velocity a burndowny jsou jen pozůstatky tradičního světa, které mají jen pramálo společného s měřením dodané hodnoty.

Asi vidíte, že změna z projekťáka na ScrumMastera není zdaleka tak jednoduchá, jak se původně zdála. Není samozřejmě nemožná, ale spousta projekťáků si na ní vyláme zuby a zůstane ScrumMasterem z donucení. Jestli se chcete stát skvělým ScrumMasterem, moje rada je, zapomeňte, že jste kdy byli projekťáky a začněte úplně od nuly. Bude to tak snazší, než když budete neustále tyto světy porovnávat.

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.

Agile jako sněhová koule

Spousta lidí si stěžuje, že oni nemůžou organizaci změnit, že to musí někdo shora. Nějaký manager. A čekají, až někdo vydá povel, příkaz, nebo změní procesy. Ale to se často neděje, a i když něco takového vznikne, jen málokdy jsou takové změny užitečné, protože managerům obecně chybí s čímkoliv agilním zkušenost. A tak si zase stěžujeme, a chceme, aby to někdo napravil, že jinak nemůžeme být ScrumMastery, Product Ownery, aplikovat Scrum, ani být agilní. Je to taková hra na schovávanou. Já bych se změnil, kdyby…

Za mě agilní transformace musí začínat u týmů. A to jak softwarových, businessových, tak i týmů executivců a po nějakém čase samozřejmě i boardu. Aby si všichni získali vlastní zkušenost s tím, jak se liší skupina jednotlivců od týmu. V kostce tým spolupracuje, důvěřuje si, jeho členové si do očí říkají i věci, kde spolu nesouhlasí, přebírají za věci vlastnictví a zodpovědnost, mají jeden společný cíl, za kterým jdou, nesoutěží navzájem mezi sebou. V podstatě je to snadné. V jednom týmu zkusíte Scrum, v jiném Kanban, v dalším třeba jen pár agilních praktik. Berete to jako experiment, který nemusí napoprvé vyjít a který pomocí rychlé zpětné vazby na retrospektivách upravujete tak, aby fungoval. A jak začíná fungovat, lidem se to líbí, úspěch se roznese a agilita se vám nabaluje jako sněhová koule. Vznikají další a další týmy, zajímají se o to další a další lidé. A zkouší si své vlastní experimenty.

Agile Journey

Když získáte dostatečnou zkušenost na úrovni jednotlivých týmů, jste ready na to začít experimentovat s agilitou na větších produktech kde vzájemně spolupracuje více týmů. Učíte se tak stavět sítě a spolupracující ekosystémy, které fungují na bázi samoorganizace, s vyšším stupněm autonomie a empowermentu. A stejně jako v předchozím kroku, je to o experimentování a pochopení agilního mindsetu a vytvoření jiné kultury.

Poslední krok je aplikace agilních principů na úroveň organizace. Je to chvíle, kdy mluvíme o Agile HR, Agile finance, Agile budgetting, Agile marketing, Agile Sales, Agile Leadership a vlastně obecně Agile mimo IT, business agility. Je to o kultuře, uvědomění si jaké máme hodnoty, a co to pro nás znamená je aplikovat do prostředí každodenních činností.

Manageři se často ptají, kdo řídí Agilní transformaci. Odpověď je většinou překvapí, protože agilní transformaci mají řídit ScrumMasteři. Ale my jsme mysleli, že to dostane na starosti nějaký manager… To se nevylučuje, ale aby to mohl dělat, musí se stát ScrumMasterem. Cílem ScrumMastera je umět tvořit self-organized týmy, komunity a systémy. ScrumMasteři jsou ti, kteří mění kulturu organizace a všeobecný mindset. Agile není o procesech, praktikách ani hierarchii, ale o jiném způsobu myšlení. A právě proto jsou ScrumMasteři ti praví, kteří by takovou změnou měli organizaci provázet. Tak ať se vám to daří.

Jestli vás téma agilních organizací a leadershipu zajímá, přijďte se o tématu dozvědět více na Certified Agile Leadership kurzu.

Stát se agilní

Zuzi Sochova BooksKdyž jsem kdysi dávno začínala se Scrumem, brala jsem ho čistě jako proces. A jako nutné zlo. Tři role, pár meetingů a backlog. Být ScrumMasterem mě nijak nelákalo. Neměla jsem pocit, že takhle pracovat potřebujeme, ba právě naopak. Mysleli jsem si, že jsme nejlepší na světě. Výborný tým, lepší, než mají zákazníci. A pak přišlo to překvapení. Tenhle děsně nudný a nesmyslný proces, rozuměj Scrum, nám pomohl. Stalo se něco, co nikdo nečekal, a my viděli pozitivní změnu. Někde tam jsem se poprvé začala opravdu zajímat o to, co je Scrum a Agile doopravdy a jak je možné že funguje. Když se na své začátky podívám, moc dobrým ScumMasterem jsem tenkrát nebyla. Nebyla to teorie, ale pozitivní zkušenost, co mě nasměrovalo na cestu agilu a opravdovému Scrumu. Začala jsem číst různé blogy, jezdit na konference, a zapojila jsem se do globální agilní komunity a zjistila, že je to skvělá skupina lidí, kteří mi vždycky když něco potřebuji pomůžou. Někde tam vznikla potřeba dát to, co jsem se naučila, zpět do lokálního prostředí. Začali jsme pořádat pravidelná agilní setkání, a hlavně Agile Prague Confernece, která přivážela špičky agilního světa do Prahy. Dnes, když mezinárodním konferencím úplně doba nepřeje, pořádáme každý měsíc Agile100 virtuální konferenci. V kostce se za ta léta ze mě stal největší Agilní nadšenec široko daleko. Ač se to zdá dávno, stále si ještě pamatuji spoustu nepochopení, špatně aplikovaných věcí a chyb, které jsme na naší agilní cestě dělali. Mám je posbírané a dnes je učím na svých kurzech, abych vám ostatním pomohla vaši agilní cestu zkrátit a zefektivnit. Spoustu jsem jich popsala na blogu a ve svých knihách. Agilní metody řízení projektů se věnují základům a praktické implementaci, Skvělý ScrumMaster (Great ScrumMaster: #ScrumMasterWay) pak roli ScrumMastera a poslední kniha The Agile Leader, která vyjde v prosinci v Americe, se dívá na agilní organizace, jejich kulturu a role leaderů v agilním světě. Když se ohlédnu, a zamyslím se, co bych doporučila těm co začínají, je to zkušenost. Zkuste si Scrum na něčem menším, abyste na vlastní kůži zjistili, jak funguje a že vám může přinést mnohdy až nečekané výsledky. Neberte věci jako dogma, ale zajímejte se, co o tom říkají ostatní, a proč fungují tak jak fungují. Buďte zvědaví a ptejte se. Jednou z nejlepších metafor na roli ScrumMastera je antropolog, který se zajímá o kulturu (culture anthropologist). Trvalo mi dlouho, než jsem se od takzvaného asistenta týmu, či maminky dostala až k antropologii. Ale zatím to považuji za nejlepší vzor pro ScrumMastera. Nejtěžší je začít. Tak s tím moc neotálejte a zkuste to. Mně se to vždy osvědčilo.

Jaký je rozdíl mezi ScrumMasterem a Agilním coachem

Jaký je rozdíl mezi ScrumMasterem a Agilním coachem? Žádný. ScrumMaster je agile coach. Je to jen jiný název pro stejnou roli. Tak proč je v tom takový zmatek a máme různá jména pro stejnou roli? To má hned několik důvodů. Ten první je, že spousta firem a ScrumMasterů nepochopila, že ScrumMaster není asistent týmu, a tak místo toho, aby roli ScrumMastera implementovala tak, jak má být a nechala je pracovat na všech třech úrovních #ScrumMasterWay konceptu ji radši přejmenovala. Druhý důvod je, že ne všichni aplikují Scrum, ti pak nazývají tuto roli agilním coachem. Třetím důvodem je, že ne všichni agilní coachové pracují na plný úvazek v jedné organizaci, aby mohli být ScrumMastery. Dělají takzvané intervence a pomáhají několika organizacím zvenku. Ti se pak většinou nazývají agilní coach.

Jak tedy poznáme dobrého ScrumMastera či agilního coache? Tak v první řadě je to agilista duší i tělem, je dobrým coachem a facilitátorem, a umí implementovat změnu v organizaci. Seniorita agilního coache ani ScrumMastera se nepozná podle toho, že je nazvete Sr. ScrumMaster ani nic podobného, ale jejich zkušenostmi a schopnostmi kde dokážou změnu implementovat – v týmu, skupině spolupracujících týmů, nebo celé organizaci. Spoustě lidem to přijde jako cool název, a tak uvidíte spoustu projekťáků, co se na agilní coache v poslední době přejmenovali. Je to teď taková móda. Když tedy chcete vědět, koho máte před sebou, nezbývá než si s ním popovídat a udělat si svůj vlastní názor o jejich osobní agilitě, porozumění agilním přístupům, umění facilitovat a koučovat, a schopnosti měnit organizace. Už něco někdy měnili a jako to šlo? Zajímá je agile? Jsou nadšení a hledají nové cesty? Jsou ready stát se servant leadery? Takový rozhovor vám poví vše, a nic dalšího vlastně ani nepotřebujete.

Když by vás ale zajímalo, jak jednoduše poznat toho agilního od toho naoko, dá se s velkou mírou jistoty říct že ti, co je role ScrumMastera zajímá, se v této roli dále vzdělávají. Mají Advanced Certified ScrumMaster A-CSM a pokračují na Certified Scrum Professional ScrumMastera CSP-SM. Obě certifikace jsou relativně nové, a tak lidí, co je mají, na trhu není mnoho. Výhoda je, že většina z těch, kteří ke mně na tyto kurzy přišli byli skvělými ScrumMastery, které bych neváhala kamkoli doporučit. Když hledáte někoho ještě o level výš, potřebujete najít lidi co mají expert certifikaci Certified Team Coach CTC, Certified Enterprice Coach CEC, nebo Certified Scrum Trainer. Všechny tři zmíněné jsou náročné, kandidáti procházejí složitým procesem, musí uspět v interview a většina zjistí, že se musí ještě hodně zlepšit, než na některou z nich dosáhne. Ale Agile je o neustálém zlepšování, takže to vlastně vůbec nevadí.

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

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🙂