Produktový vlastník je jedna z nových rolí, na kterou se odkazuje zejména scrum. Pro agilní transformaci je tato role naprosto klíčová. Produktový vlastník musí mít vizi, musí ji umět přetavit na uživatelské scénáře a musí být schopen spravovat očekávání zákazníků. Musí zvládat umění dělit velká zadání na malé, konkrétní úkoly, které dokáže malý tým (pro konkrétní představu 6+-3 členů) plnit tak rychle, že je v reálném čase možné sledovat pokrok. (… ) Na základě mých osobních zkušeností a pozorování je právě nepochopení a podcenění této role největší překážkou agilní transformace. Nestačí pouze přejmenovat a přeškolit projektové manažery na produktové vlastníky. Jde o mnohem víc. (Str. 67)

nutnost podpory managementu (a rizika open space, outsourcingu, nenahraditelných zaměstnanců), potřebné fungování týmu (Schůzky a mítinky, Denní scrum, Sprint, jeho plánování a revize, Vydání nové verze, Retrospektiva sprintu, Správa chyb, Každodenní priority, Transparentnost) až po empirickou podporu procesů a škálování.

Učebnicový scrum třeba roli testera vůbec neuvádí – týmy jsou pouze vývojové a správně by měly mít všechny schopnosti potřebné k dodání produktu. Jednou z těchto schopností může být třeba i schopnost manuálního testování – schopnost předvídat chování uživatelů. Testeři v agilních vývojových týmech by proto měli sami sebe přestat vnímat jako audit kvality, který svým podpisem stvrzuje použitelnost řešení v produkčním prostředí. Stejně tak hnidopiši („máš tam chybu – koukej si to opravit“) a mistři obskurních scénářů to budou mít v agilních týmech nelehké. Než pálit čas hledáním chyb v nikým nepožadovaných částech funkčnosti a jejich opravami, měl by se celý vývojový tým společně soustředit na zamezení samotného vzniku chyb. Kvalita musí být zabezpečená napříč celým životním cyklem produku. Měřit na samotném konci tohoto cyklu, zda tam je, ji nijak nezabezpečí. (str. 41)

Knihu uzavírají přehledové tabulky:

• Velmi zjednodušené srovnání tradičního a agilního přístupu k vývoji softwaru
• Velmi zjednodušené srovnání scrumu a kanbanu
• Nejzákladnější předpoklady pro zavedení scrumu
• Jak může management bránit agilní transformaci
• Jak může management podpořit agilní transformaci
• Kombinování scrumových rolí
• Nejčastější chyby při agilní transformaci
• Nejčastější chyby scrum masterů

Ty se mi zpočátku zdály nadbytečné, ale když jsem si v nich zakládal už třetí stránku, uvědomil jsem si, že obsahují opravdu shrnutí důležitých postřehů. Třeba u chyby, kdy je agilní jenom vývoj a ne zbytek společnosti (Str. 189) jsou vyjmenované možné důsledky:

• (...)
• management nijak nemění svá očekávání od vývoje (proto právě název "fixed requirements agile neboli fragile"),
• riziko vzniku jiných zdrojů práce, než je produktový vlastník,
• bez ohledu na plánování hrozí přidávání další urgentní práce do iterací bez možnosti odmítnutí, byť jen části, protože všechno je důležité,
• odhadování náročnosti úkolů v časových jednotkách a následné vyžadování tyto odhady dodržet: odhad = závazek,
• (...)

Do kamene tesat. Ačkoliv bych tedy naprostou většinu věcí v knize podepsal (a pro mě je to potvrzení, že se opírá o realitu a to včetně reality velkých firem a korporací), nebudu zastírat, že pár věcí mě překvapilo a musel jsem si trochu poopravit svůj přístup. Například tohle:

I v tomto případě pořád platí, že zpřesňování zadání by mělo probíhat mimo produktového vlastníka. Ten by se měl správně soustředit na backlog a připravovat zadání, které tým bude vyvíjet v budoucnosti. Ne fungovat jako zákaznická proxy. Není v lidských silách, aby jeden vlastník odpovídal na doplňující otázky deseti členů vývojového týmu a zároveň hledět do budoucnosti. Vývojový tým by měl chybějící části potřebné k implementaci doplňovat sám. (Str. 70)

To mě trochu míjelo (i když praxe k tomu vede jaksi samovolně právě kvůli kapacitě).

Produktový vlastník nenařizuje týmu, jak výsledný přírůstek hodnoty dodá, ani výsledný přírůstek týmu neakceptuje. Poskytuje na něj pouze zpětnou vazbu. Musí vývojovému týmu nejdřív věřit, že svěřené zadání zvládne dodat a pak poskytnout zpětnou vazbu na výsledek. Tím vzniká prostor pro učení a schopnosti týmu i produktového vlastníka společně rostou. (Str. 72)

Kromě znalostí a praxe disponuje autor i schopností tvrzení pěkně pointovat, například u review:

Revize by rozhodně neměla být žádná práce navíc. Nemělo by se například stát, že ve dvoutýdenním sprintu strávíte jeden týden přípravou prezentací pro demo. Předvádí se hotový software – pokud váš software potřebuje speciální přípravu, aby ho bylo možné předvést, hotový není. (Str. 133)

nebo u škálování:

Pokud pojedete na konferenci nebo do agilní kavárny, určitě tam potkáte nějakého nadšence, který bude obhajovat tu nebo onu metodu škálování. Jak musíte eskalovat, když narazíte na problém, jak efektivně sdílet informace, scrumy scrumů, denní scrumy scrum masterů atd. Víte proč tyto vize budou kolidovat s praxí, kterou prožíváte? Ten nadšenec nebude lopata. (Str. 166)

Založil a vypsal jsem si toho ještě mnohem víc, cílem recenze ale není knihu převyprávět. Takže jen závěrečné shrnutí – v češtině docela jistě není lepší kniha o agilním vývoji, a pokud se s ním jakkoliv setkáváte, musíte ji mít.

Aktualizace 1. 12. 2022: V relativně krátké době jsem si pročetl knihu podruhé, abych si poznámky oživil a nezapomněl něco důležitého v práci aplikovat – agilní transformací totiž procházíme. A to celofiremně, mění se struktura i fungování, podpora agility je na všech úrovních. Což je jeden ze základních předpokladů:

Pokud jste se opravdu rozhodli agilní vývoj zkusit, prvním a nejdůležitějším předpokladem úspěšné agilní transformace je vytvoření prostředí pro změnu. V prostředí, které agilní transformaci neumožní, transformace nevydrží. Firemní kultura musí transformaci umožnit. Ve velkých zavedených skupinách myšlení a kultura následuje formální organizaci těchto skupin. Jinak řečeno, organizační struktura má velmi silný vliv na myšlení a chování svých členů. Dokud se nezmění organizační systém (skupiny, role, hierarchie), nezmění se chování a myšlení jednotlivců. Společnosti, které deklarují záměr agilně se transformovat, musí být připraveny odpovídajícím způsobem nejprve změnit svojí organizační strukturu. Lidé ale samozřejmé nechtějí přijít o práci kvůli organizační změně a tato obava se může projevovat jako neochota k jakékoliv změně. Rozhodnutí pro agilní transformaci tedy ve skutečnosti znamená rozhodnutí změnit stávající firemní strukturu. (Str. 27)

a také potvrzení, že se to bere za správný konec. Teď už si doplním jen pár dalších citací, které by se mohly hodit. Rozdíl mezi projektovým manažerem a produktovým vlastníkem:

Projektový manažer spravuje zdroje. Nese odpovědnost za včasné dodání výsledků dle předem odsouhlasené specifikace. Soustředí se na rozpočet, časový plán a vymezený rámec projektu (z anglického „scope"). Přesto, že má obrovskou odpovědnost, má pouze nepatrný vliv na celkový koncept projektu. Někteří projektoví manažeři vedou projektové zdroje volně, jiní drží vše pod drobnohledem.

(… )

Produktový vlastník se naproti tomu soustředí na vizi. Nesleduje pouze pasivně postup k cílům, ale s postupem prací se od něj očekává i přehodnocování původně stanovených cílů a změny jejich priorit. Musí být zmocněn činit i důležitá rozhodnutí a tato rozhodnutí nesmí být zpochybňována. Jeho autorita je založena na důvěře zákazníků a partnerů, že pomůže vývojovému týmu pochopit požadavky a očekávání. Na základě těchto očekávání pak vývojový tým dodává hodnotu formou přírůstků hodnoty produktu. Produktový vlastník v sobě z tradičních rolí kloubí schopnosti manažera, marketéra, analytika a akceptačního testera. (Str. 93)

Problém se změnami obsazení týmu:

Až poslední, nad čím byste měli přemýšlet, je pokrytí chybějících znalostí novým členem týmu. Každý zásah do organizace týmu totiž srazí tým do fáze formování a výrazně ovlivní jeho výkonnost. (Str. 140)

Když už je tým rozptýlený, tak pozor na osobní schůzky s jeho částí:

Když pak vznikne potřeba konference s celým týmem, musí mít všichni členové stejně špatné podmínky. Pokud například prezentér sdílí kancelář s jednou částí rozptýleného týmu, měl by se na společné schůzky přihlašovat z domova. Jinak to bude budit zdání, že je část týmu protěžována. Ta část týmu, se kterou sdílí prezentační místnost, rozhodně bude prezentéra líp slyšet. A prezentér zas je. A prezentér může klidně být nadřízeným manažerem celého týmu a pocit protekce je na světě. (Str. 176)

Odkazy: