Tag: feedback

Nejčastější nepochopení Scrumu

Scrum je velmi jednoduchý framework. Bohužel ale není vůbec snadný aplikovat. Je to velká změna myšlení, přístupu, hodnot. Když se půjdete do běžné firmy podívat, tohle asi budou nejčastější nedorozumění, a nepochopení, na které narazíte:

Scrum

Daily Scrum jako status meeting

Daily Scrum alias Standup meeting je tak triviální věc, že by jeden řekl že se snad ani nedá zkazit. Chyba lávky. 80% firem ho bere jako status meeting, kde každý jednotlivec referuje (managerovi, ScrumMasterovi, nebo ostatním členům týmu) co dělal. A kosmetické změny ScrumGuidu, které se snaží vysvětlit, že je to celé o synchronizaci týmu, jejich diskusi, jak dosáhnou cíle Sprintu (Sprint Goal), zůstávají bez povšimnutí. Kde jinde bychom ty líné vývojáře kontrolovali a řídili, vždyť jinak nebudou nic dělat.

“Cílem Daily Scrumu je synchronizace členů týmu a jejich dohoda, jak budou dále pracovat na dosáhnutí cíle Sprintu, tedy Sprint Goalu.“

Sprint Backlog se nesmí měnit, je klíčový

Když už jsem zmínila Sprint Goal, pojďme u něj zůstat. Většina firem žádné Sprint Goaly nepoužívá. Vystačí si se Sprint Backlogem, který navíc mylně vnímá jako neměnnou specifikaci, která do detailu popisuje, co přesně má tým (rozuměj ‘coding monkeys‘) naimplementovat. Sprint Backlog je ale jen rámcovou dohodou, jak chceme dosáhnout cíle Sprintu. Klíčovým artefaktem je Sprint Goal, který definuje, čeho z pohledu business value chceme dosáhnout. Ten by se měnit neměl, protože to je to do čeho v rámci Sprintu investujete. Sprint Backlog se naopak v závislosti na situaci a dohodě týmu klidně měnit může. V podstatě s tím, jak se ve Scrumu začal Sprint Goal více používat, přestal být Sprint Backlog téměř potřeba, natož aby byl neměnný.

“Sprint Goal definuje smysl Sprintu, čeho chceme z pohledu business value dosáhnout. Sprint Backlog nám pouze pomáhá udělat dohodu ‘jak’ toho chceme dosáhnout. “

Sprint Review je o akceptaci

A do třetice všeho dobrého, nebo spíš zlého :), takové běžné Sprint Review alias Demo velmi často skončí jako prezentace technických scénářů Product Ownerovi. Proč prezentujeme něco někomu, kdo měl být celou dobu přitom, je mi záhadou. Někde prezentujeme Product Ownerovi proto, že nikoho jiného technické scénáře nezajímají, jinde protože se bojíme členy týmu komukoli ukázat, aby neudělali ostudu, jinde ani Product Owner nechodí a děláme to jen protože Scrum. Sprint Review je klíčovým prvkem Scrumu, protože právě tady získáváme zpětnou vazbu na doručený Sprint Goal, tedy funkční inkrement produktu, nebo jinak řečeno dodanou business hodnotu. Jdeme správným směrem? Je tohle opravdu business hodnota? Dosáhli jsme očekávaného impactu? To jsou otázky, které je dobré si v rámci Sprint Review položit.

“Cílem Sprint Review je získat zpětnou vazbu od zákazníků, stakeholderů, uživatelů abyste se na jejím základě mohli adaptovat. Je to klíčovým prvkem a by vám fungoval proncip Inspect and Adapt.“

 

Jestli jste se ve výše zmíněných příkladech nepoznali, dobrá zpráva. Asi jste se už vymanili z područí ‘Technického Scrumu’, nebo ’Dark Scrumu’ a jste o krok blíže změně mindsetu. Jen tak dál 🙂

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.