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 🙂

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.

Žádný meeting ve Scrumu není klasický status meeting

Víte, že žádný meeting ve Scrumu není klasickým status meetingem?

Daily Scrum (Standup meeting)

Začněme Standupem, kde antipaternem je, že jednotliví členové týmu reportují, co všechno dělali a co dělat budou. Asi aby je ScrumMaster nebo ostatní členové mohli kontrolovat.

Standup je tu ale proto, aby se tým a jeho členové každý den rychle zastavili a řekli si, jestli jdou správným směrem a jestli ještě stále věří tomu, že zvládnou dodat Sprint Goal. Proto nekontrolujeme, čím trávili čas, ale soustřeďujeme se na to, co je hotovo, a jak budou spolupracovat na tom, co mají teprve dokončit.

Sprint Review

Dalším v řadě je Sprint Review, kde antipatern je prezentovat, které konkrétní UserStory se dokončily a které ne. Spousta týmů status dotáhla do dokonalosti a dokonce ukazuje prezentaci a jakési grafy a vyhodnocuje úspěch a neúspěch Sprintu.

Sprint Review je tu ale proto, abyste ukázali Potentional Shipable Product Increment – tedy to, co tým dokončil – zákazníkovi a získali na základě toho zpětnou vazbu. Ta je potom cenným vstupem pro Backlog Refinement a pomáhá vám dodat úspěšný produkt.

Retrospektiva

Do třetice je tu Retrospektiva, kde antipaternem je začínat Retrospektivu tím že procházíte jednotlivé body z minula a hodnotíte, jak se vám povedly dokončit a jestli zabraly na daný problém.

Retrospektiva ale má být kreativním workshopem, kde se tým zamýšlí nad tím, co by chtěli změnit, co jim vyhovuje, co naopak chtějí zlepšit. Aby fungovala, musíte se na sebe umět podívat jinýma očima, z venku. A když začnete statusem, tak ten nadhled ztratíte a v další fázi pak jen zopakujete, co vám zbylo z minula. Máte-li pocit, že se věci nehýbou kupředu, určitě to na další retrospektivě zazní znovu i bez opakování. A status těch pár Action Items z minula můžete dát na tabuli a skouknout na Standupu.

Agilní praktiky XP – Kolektivní vlastnictví kódu

Chcete-li mít tým potažmo SW firmu opravdu efektivní, musíte se řídit pravidlem, že nikdo nevlastní kód ani jeho část. Narážíte-li na námitky vývojářů že to nejde, neboť jen oni opravdu rozumí dané části aplikace a ostatní by jim to jen zkazili, není to nikterak neobvyklé. Stačí věřit tomu, že to jde a mít schopnost zavést týmové metody spolupráce. Třeba Scrum proces nebo agilní metody řízení softwaru 🙂

Agilní praktiky XP – Kolektivní vlastnictví kódu

Abyste mi věřili, že to je možné i ve velmi složitých prostředích kritických na jakoukoli chybu, přikládám následující case study.

Case Study – “NENAHRADITELNÝ JAMES”

Prostředí
Mezinárodní firma operující v life critical oblasti, přes 50% světového trhu v daném sektoru. Vývojová centra v několika zemích.

Projekt
Migrace všech aplikací na novou platformu pro divizi A. Přes 60 aplikací, čtyři odlišné architektury. Několik sdílených knihoven a klíčových oblastí.
Současně s migrací probíhal vývoj nových funkcionalit v rámci původních aplikací na originální platformě.

Původní stav
Každá sdílená oblast měla jednoho vlastníka (skupinu vlastníků), který oblasti skvěle rozuměl, a nikdo jiný nebyl oprávněn oblast měnit.

Nejvíce kritická situace nastala v klíčové knihovně využívané všemi 60 aplikacemi. Tu měl na starosti James, který ji před mnoha lety navrhl, vymyslel, naimplementoval a celou dobu dělal všechny potřebné změny pro jednotlivé aplikační týmy.

Vzhledem k jeho unikátním znalostem a komplexitě problému bylo řešení v lokálním měřítku optimální, a jeho kapacita stačila požadavkům okolí.

Koncový stav
Po startu migrace, začal být velmi rychle James zahlcený požadavky na změnu knihovny, která byla sdílená přes nové i staré aplikace a v rámci migrace se musela výrazně měnit. Nepomohlo ani to, že některé týmy navrhovaly přímo konkrétní implementaci řešení, kterou stačilo zrevidovat a použít. Čekací doba na změnu kritickou pro migrační projekty byla několik měsíců, což ohrožovalo projekt jako celek.

Řešením byla změna přístupu k této sdílené knihovně a odstranění unikátního postavení Jamese, který už nadále nemohl knihovnu vlastnit a být jejím výhradním přispěvovatelem. Z knihovny se stal sdílený kód, ke kterému měly přístup všechny týmy. Nebyly zpočátku sice tak efektivní jako James, ale průchodnost systému jako celku se odblokovala. Změny samozřejmě probíhaly za Jamesova dohledu a podléhaly revizi Jamese i týmu architektů, aby se předešlo problémům s kvalitou.

Podobné oblasti jsou ve všech větších firmách s komplexnějším prostředím a udělat z nich sdílený kód obvykle pomůže systému jako celku.