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:

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 🙂