Tag: zpětná vazba

Pozice, platy a zpětná vazba v Agilní firmě

Tím, jak se firmy stávají více Agilní a týmově orientované, přestává systém pozic dávat smysl. Pozice totiž lidi škatulkují a uzavírají do konkrétního znalostního sila. A my chceme cross-functional týmy, lidi, kteří se dokáží na věci podívat out of the box. A tak firmy často přicházejí s tím, že pozice prostě nemají. Když se nad tím zamyslíte, dává to perfektně smysl. I v softwarovém světě, když máte analytika, developera a testera, máte spoustu problémů s tím, že developer přeci nemůže napsat test, a musí počkat až mu někdo řekne, co má vlastně implementovat. Ale když spolupracujete jako tým, záleží daleko víc na tom, jaké máte schopnosti a znalosti, než jak se jmenuje vaše pozice. Zkuste to, změňte pozice na SW Engineer a uvidíte co se stane. Časem lidé ze svých škatulek vykouknou a začnou se zajímat o práci okolo. Jak dodáme lepší hodnotu zákazníkovi. Jak máme pracovat, aby nám to lépe šlo? Hele, je tu workshop o kvalitě kódu. Půjdu se podívat. Protože se mě to jako toho, kdo s kódem pracuje, týká. Je tu diskuse o tom, jak dělat UX, zapojím se, protože mě to stejně vždycky zajímalo, a něco se dozvím. Některým aktivitám se věnuji víc, jiným míň. Je to podobné americkým universitám, kde si student sám skládá program studia. Prostě mu věříme, že je dostatečně inteligentní, aby se sám za sebe rozhodl, čemu se bude věnovat a co bude nejlepší pro život. Proč to pak nejsme ochotni udělat ve firmách, a věřit zaměstnancům, že se dokáží rozhodnout, čím má smysl se zabývat a čím ne, co firmě jako takové pomůže, a co bude zbytečné?

Takže když už jste zrušili pozice, co platy? Ty přeci máme na pozice navázané. Ano, takový systém mají firmy často. Musíte být manager, abychom vám přidali, no tak budete manager, ale protože vlastně lidi řídit neumíte a ani nechcete, tak nebudete mít podřízené. Nedávno jsem v jedné takové firmě byla. Jen jeden z 5 managerů měl podřízené, ostatní byli zkušení lidé, o které firma nechtěla přijít. Byla ochotna jim zaplatit víc, protože jí přinášeli hodnotu, ale nemohla. Tak to vyřešili kreativně a pravidlo obešli. Bez ohledu na to, jaké máte pozice, oddělte od nich platy. Jsou to dvě věci, které spolu nemají moc nic společného. Umožní vám to výjimečné lidi výjimečně ocenit. A jak je ocenit, když na to není tabulka? Dejte jim transparentní pravidelnou zpětnou vazbu, jak je firma vidí. Jak jsou přínosní tím, co dělají svým kolegům, jak týmy hodnotí zákazníci a stakeholdeři, a jak je produkt, na kterém pracují, úspěšný jako celek. Na začátku věty jsem zmínila transparentní a pravidelnou zpětnou vazbu. Tedy ne za zavřenými dveřmi jednou ročně. Pravidelná zpětná vazba je užitečná, protože nutí lidi se zamyslet co uděláme příště jinak, co změníme. Nekritizujte, ale nabídněte pomocnou ruku, pomůže lidem být úspěšnými.

Sprint Review

Sprint Review je jednoduchý meeting, který ale většina firem nepochopila. Jak se jako Agilní Coach chodím dívat na různé Scrum týmy, nejčastější chybou je, že Sprint Review považují za Sprint nebo Release status. A tak se tenhle zajímavý meeting stává pro spoustu firem noční můrou. Rozhoduje se zde, jestli byl tým úspěšný, kolik slíbil a kolik dodal. Ale to je zcela mimo definici toho, co by se tu mělo dít.

Jestli jste si oddychli, že takhle to u vás není, mám pro vás druhou nejčastější chybu, a to že na Sprint Review prezentuje tým Product Ownerovi co dokončil. Je to asi o chlup lepší, ale pořád úplně vedle. Product Owner je součást Scrum týmu a tedy dokončenou funkcionalitu akceptuje hned jak je hotová, tedy v průběhu Sprintu. Tedy na review už ji dávno viděl a dal na ni zpětnou vazbu.

Další chybou v pořadí je, že neprezentuje tým, ale Product Owner. Tým je přeci banda introvertů co nerozumí businessu, tak jak by mohli předstoupit před zákazníka, že? No alespoň oproti předchozím variantám něco ukazujete zákazníkovi a dostáváte zpětnou vazbu. O tu jde totiž na Sprint Review především.

Ideálním stavem je, že tým prezentuje zákazníkovi, co dokončil. A na oplátku získá zpětnou vazbu od zákazníka. Není to žádná technická prezentace jak je to naimplementované, ani přehlídka jednotlivých User Stories, ale souhrnná prezentace toho, jak jsme doručili za daný Sprint hodnotu definovanou cílem Sprintu.  Jak již jsem naznačila, prezentuje tým. Kdo konkrétně? No to je snadné, kdokoli. Z výborně fungujících týmů je schopný hodnotu Sprintu prezentovat kdokoli. Jak to vypadá v praxi? Přijdete na Sprint Review, tým vylosuje jednoho člena a ten prezentuje. Že to není možné? Když tým spolupracuje v rámci Sprintu vždy na jedné UserStory (viz praktika “One UserStory at a time“), není to problém. Je důležité si uvědomit, že neprezentujeme detailní řešení, ale Sprint Goal, tedy hodnotu dodanou v daném Sprintu.

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.