Sprint Review

Jak na Scrum Eventy

Když to řeknu jednou větou, Scrum je iterativní a inkrementální styl práce, zaměřený na týmovou spolupráci a maximalizaci business hodnoty. Nic složitého. To ale neznamená že ho organizace hned napoprvé implementují správně. Scrum totiž mění poměrně hodně zažitých věcí. Tentokrát bych se chtěla podívat na eventy. A jen tak mimochodem, neříkáme jim ani “ceremonie“ (které týmy dělají jen tak naoko, protože Scrum říká že se to musí), ani “meetingy“ které někdo pro tým musí zorganizovat. Event je bližší slovu “happening“. Tedy něčemu, co se děje skoro by se dalo říct samo od sebe, protože všichni chtějí, aby se to dělo. Nikde se nic nemusí plánovat, všichni vědí, kde a kdy event je a účastní se, protože jim to připadá užitečné a smysluplné.

Eventů je ve Scrumu pět a se dějí pravidelně. Mají sice definovanou maximální délku, ale je dobré vědět že pro kratší Sprinty eventy trvají významně kratší dobu. Důležitá je hlavně pravidelnost. Tím, že se dějí pravidelně, pomáhají týmu ale i zákazníkům si na iterativní styl práce zvyknout a lépe plánovat, připravovat se, a vědět co se děje.

Asi nejčastější problém je, že se týmy snaží aplikovat Scrum na jednotlivce místo na tým a že v Product Backlogu mají nahodilé tásky, nikoliv položky backlogu definující business hodnotu. V takovém prostředí většina eventů nefunguje, protože jsou založené na týmové spolupráci a dodávání hodnoty. Ze Sprint Planningu se stane alokace práce pro jednotlivce, z Daily Scrumu se stává micromanagerský otravný meeting, Sprint Review ukazujeme jen tak sami sobě, protože drobné činnosti vlastně nikoho nezajímají, a na Retrospektivě si postěžujeme, jak nám ten Scrum nefunguje. Nic, co byste chtěli zažít. A nemá ani moc cenu nutit jednotlivce Scrum eventy vykonávat, dokud místo skupiny jednotlivců nemáte tým a dokud v Product Backlogu nemáte opravdové položky backlogu zaměřené na hodnotu. V momentě, kdy se tyto dvě věci spraví, dějí se eventy vlastně samy od sebe, protože týmu pomáhají se lépe zorganizovat a dosahovat větší hodnoty pro zákazníka.

Když budete mít tým a relevantní Product Backlog, zbývá už jen vysvětlit k čemu jednotlivé Scrum eventy jsou a jak by měly vypadat. A na to se podíváme v následujících příspěvcích: Sprint, Sprint Planning, Daily Scrum, Sprint Review, Retrospektiva.

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.