Tag: produkt

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

Top 5 bodů co dělá Agilní transformaci úspěšnou

1.    Proč?

Asi úplně nejdůležitější je mít cíl. Proč byste se vůbec měli měnit. Protože jestli vše funguje dobře, firma prospívá a je businesově úspěšná, možná si nechte to, co máte. Ne každý musí být Agilní. Když najdete dostatečně kritický důvod pro změnu, určitě se vám to podaří. Důvody pro Agilní transformaci tedy musejí být strategické z pohledu organizace.

2.    Postoj a pochopení managementu

Druhým střípkem do mozaiky úspěšné Agilní transformace je pochopení managementu. Co tedy management musí pochopit? V první řadě že Agile je změna mindsetu – tedy kultury, přístupu k věcem, myšlení. Není to jen další proces, který bezmyšlenkovitě implementujete a je to. Bude to stát hodně energie na všech vrstvách firmy. Aby se transformace podařila, musíte ve firmě musíte budovat silný Agile Leadership a pomoci managementu se do transformace zapojit, být její součástí a řídit její směr.

3.    Definice Produktu

Dalším důležitým bodem je vědět co děláme. Agilní svět opouští tolik oblíbené projekty a plánuje práci pomocí Product Backlogu. Staví na dobrých Product Ownerech, kteří mají vizi a vědí čeho chceme jako firma dosáhnout.

4.    Experimenty

Dalším bodem, který je pro úspěch Agilní transformace nutný je ochota experimentovat. Určitě si říkáte, že na tom nic není. Ale kolik z vás je ochotno přijmout, že hodně experimentů se nepodaří a jsou tak dobrou příležitostí pro zlepšení? Kolik z vás bere chybu jako příležitost k poučení se? To vše je vlastně Inspect and Adapt princip, který je podstatou celého Scrumu. Experimentujete a hledáte cestu? V produktu i vlastním fungování? Pak jste Agilní. Odmítáte takovou možnost jen připustit a hledáte jednoduché recepty? V Agilní transformaci nic takového nenajdete.

5.    Trpělivost a odvaha

V neposlední řadě je to trpělivost a odvaha. Trpělivost proto, že taková změna se nestane přes noc a pro velkou korporaci je Agile cesta která trvá několik let a vlastně nikdy úplně nekončí. Agile je o neustálém hledání lepší cesty, neustálém zlepšování. Dobrá zpráva je, že výsledky přijdou hned jak se na cestu dáte, tedy už po pár Sprintech. Odvahu proto, že budete dělat věci jinak než dřív, a dost možná i jinak než ostatní kolem vás. A to odvahy vyžaduje docela dost. Budu vám držet palce 🙂

Proč máme Product Ownera

O roli Product Ownera toho bylo napsáno hodně. Přesto však některé firmy nepochopily jeho význam a berou takového člověka jako administrativní sílu. Ostatně, kdo jiný by měl mít čas být týmu k dispozici a psát jasné a konkrétní User Story. Product Manager na to nemá čas, v lepším případě je furt u zákazníka, v horším řeší takových produktů několik nebo jen tráví většinu času na obecných firemních mítincích a stihnout to ani při nejlepší vůli nemůže. V obou případech se pak velmi často setkáváme s modelem, kdy o všem rozhoduje Product Manager, který ale nemá čas, a takzvaný Product Owner se na všechno chodí ptát, protože o čemkoli rozhodne, stejně Product Manager shodí při customer demu ze stolu. Vychází to z neochoty a často i neschopnosti delegovat, nesmyslné organizaci, a také toho, že takový Product Owner není nositelem vize a sám jí často nerozumí. Jak se to pozná? Zeptejte se ho, proč by tým měl na produktu pracovat. Většina takových Product Ownerů odpoví něco ve smyslu, že to asi firma potřebuje… že… Když tím testem přeci jen projde, obvykle se zasekneme hned na další otázce, proč děláme tuhle User Story. A kde je její business value. Co přinese zákazníkovi? A obvyklá odpověď je ‘no Product Manager nebo zákazník to tak chce‘. Kde se pak má brát motivace a zapojení týmu a proč by zrovna na tomhle produktu měli pracovat?

Samozřejmě i takové rozdělení role Product Ownera mezi více osob může fungovat. Jeden příklad z nedávné praxe. Máme Product Managera co nemá moc čas. Je to vizionář, většinu času cestuje po světě a je v letadle. Oblítává zákazníky z různých koutů světa, vymýšlí inovace, dívá se, co má konkurence. Aby tým nebyl od produktu odtržený, není tento člověk vnímán v roli plného Product Ownera, ale spíše interního zákazníka, co chodí s high-level nápady. Product Owner je s ním v častém kontaktu, sdílí spolu nápady a vize, přemýšlí, co by se mělo jak udělat, co změnit. Product Manager je zodpovědný za budget a celkový úspěch produktu na trhu. V podstatě by šlo i říct, že definuje Backlog na úrovni Epiců maximálně velkých Super User Stories, zatímco reálný Product Owner se za pomoci týmu stará o to, aby vznikla správná granularita User Stories a tým byl na produkt, vizi a business value napojený. Je součástí Backlog Groomingů, je zodpovědným za Product Backlog, jeho hodnotu a porozumění týmu. Výhodou je, že takový Product Owner má v roli Product Managera zástupce, a když se stane, že z nějakého důvodu není k dispozici, tak Product Manager převezme jeho roli a tvoří s týmem User Stories. Je to tedy jen o lidech. Tihle to zvládli rychle a nejsou zdaleka jediní. Ale není to bohužel zdaleka tak obvyklé, jak by bylo potřeba.

Další obvyklý problém v této oblasti je neschopnost firem se nad portfoliem produktů zamyslet a nějak je omezit nebo prioritizovat a serializovat. Takové firmy si myslí, že tím, že se na produktu už pracuje, je zajištěna jejich úspěšnost. Musíme dělat všechno najednou. A tak se některé firmy podobají střelcům s automatickými zbraněmi, co sice mají zavázané oči, ale o to více střílejí kolem sebe. Čím více výstřelů, tím větší pravděpodobnost že se do něčeho nakonec trefíte… S takovou strategií vám v efektivitě a úspěšnosti nepomůže nic. Ani Agile, ani krásný formát User Stories. Role Product Ownera je tu proto, aby se někdo staral o to, co nám to přinese a s pomocí agilních metod dostal na business nápady rychlou zpětnou vazbu. Když se to neosvědčilo, zahoďte to a zkuste něco jiného. Ale na to musíte mít již v začátku jasnou představu, co chcete dosáhnout a jak poznáte, že se to povedlo. Jinak střílíte kolem a doufáte, že se to tentokrát povede. Agile a Scrum není jen o týmu a spolupráci, ale je o napojení na business a zpětné vazbě. Je o schopnosti prioritizovat. A to nejen na úrovni User Stories a každého produktu, ale i produktů v rámci firmy. A to se bohužel ve spoustě firem neděje.

Jak vypadá Scrum, jak Scrum Master, jak má Scrum Master motivovat tým a jak řídit produkt

Jsou to zdánlivě nesourodé otázky, ale dalo by se říct, že po shlédnutí příslušných videí budete vědět, jak vlastně agilní metody fungují.

Jak vypadá Scrum?

Začneme krátkým úvodem Scrum ve 13s.

Že jste se toho moc nedozvěděli? Pusťte si video ještě jednou, a zjistíte že Scrum je iterativní proces, v každém cyklu dodává nějakou část, která má hodnotu. Zjistíte, že existuje něco jako Product Backlog, ze kterého se před každou iterací vybere pár celků, které tým v jednotlivých dnech zpracovává a které na konci iterace dodá jako hotové a nasaditelné. Na dokončené kousky se dívají ti, co k produktu mají co říct, tedy zákazníci, business, uživatelé a z jejich zpětné vazby vznikají požadavky na změnu, nové funkcionality, či funkce které můžeme oželet a ty se hned promítají do Product Backlogu. To je na 13s vaší pozornosti informací až až.

Kdo je to Scrum Master a jak spolupracuje s týmem?

Video má tentokrát asi 5min a uvidíte v něm jak se Ian jako “Super Scrum Master“ stará o svůj tým. Že byste to dělali jinak? Proč ne. Podstata je ale stejná. Všichni včas na Standup, nerušit tým změnou priorit, dodržovat done kritéria, brát testování jako součást úlohy. Scrum Master musí dělat to co je potřeba. Je coach a facilitátor. Je to o týmu. Ne o Scrum Masterovi. Ale bez dobrého Scrum Mastera nikdy nebudete mít dobrý tým.

Jak má Scrum Master motivovat tým?

A jak je téma složitější, prodlužuje se délka videí. Tohle je na přibližně 20min, ale opravdu stojí za zhlédnutí do konce. Přesně takhle totiž funguje motivace. Italy Talgam demonstruje na ukázkách různých dirigentů a orchestrů jak funguje leadership. Ve kterém orchestru byste chtěli pracovat? A který dirigent by byl dobrým Scrum Masterem? To určitě posoudíte sami.

Jak řídit produkt?

Poslední video je nejdelší, ale také je více nabito informacemi. Vytvořil ho Henryk Kniberg a myslím, že stejně jako jeho knihy Scrum and XP from the Trenches nebo Kanban and Scrum – making the most of both je i tohle velice pěkně vytvořené video kde se dozvíte vše co jste kdy potřebovali vědět o produkt managementu a roli Product Ownera.

Originál spolu s přepisem textu nejdete zde.