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.

Jak může vypadat Product Backlog – Příklad

Jak tak školím různé kurzy, spousta lidí se ptá, jestli mám někde příklad Product Backlogu. A já nikdy nevím jak jim vysvětlit, že je to snadné a nic složitého na tom není. Můžete začít hned. Stačí vám pro to takové ty malé podlouhlé papírové kartičky, anebo jednoduchý Microsoft Excel, či Google Sheet.

Nejjednodušší variantu Product Backlogu si můžete představit jako kartičky  (jeden sloupec Excelu), kde jednotlivé funkcionality jsou například:

Automatický výběr piva na párty
Vybrat nové pivo na ochutnání
Objednat oblíbené pivo
Doporučit drahé pivo

Jak asi víte, nejčastější formou psaní Product Backlog Items je User Story. V takovém případě Backlog obvykle rozšíříte o jméno a takzvané Conditions of Satisfaction.

Jméno
UserStory
Conditions of Satisfaction

Automatický výběr piva
Jako Jon (zaneprázdněný manager) chci, aby mi “Beerer” vybral piva na párty, abych mohl různorodým výběrem oslnit přátele.
Jon překvapí své přátele výběrem z lokálních pivovarů po celém světě a pivy různých chutí.

Vybrat nové pivo na ochutnání
Jako Jon chci zobrazit katalog piv, abych si mohl vybrat nějaké nové pivo na ochutnání.
Jon může porovnat piva podle chutí přímo z katalogu.

Objednat oblíbené pivo
Jako vracející se zákazník chci vidět oblíbená piva, abych si je mohl znovu objednat.
(může zůstat prázdné – conditions of satisfaction nejsou nutná).

Doporučit drahé pivo
Jako vlastník obchodu chci, aby “Berrer” doporučovat přednostně drahá piva, abych měl větší zisk.
Zákazníci se necítí pod tlakem moc utrácet.

Popřípadě můžete ještě přidat několik volitelných položek jako: ID, Estimate, Epic, a Priorita.

ID PBI Estimate Epic Priority
234 Automatický výběr piva na párty 20 Order 1
556 Vybrat nové pivo na ochutnání 8 Order 15
123 Objednat oblíbené pivo 3 Order 40
89 Doporučit drahé pivo 5 Profit 50

No a to je vše. Jak vidíte, není na tom nic složitého, nic co by vyžadovalo žádné komplexní nástroje složitější než podlouhlé papírové kartičky nebo Excel Sheet. Zkuste a uvidíte.

Backlog Grooming

Také se ptáte k čemu je Backlog Grooming? Cílem tohoto meetingu je zajistit, aby tým rozuměl celému Backlogu. Proto na úplně prvním Groomingu začínáme tím, že Product Owner v 15ti minutách představí vizi produktu /releasu a všechny Epicy. V druhých 15ti minutách představí střední vrstvu Backlogu, tzv. Super User Stories – tedy předpřipravené funkcionality, které přijdou na řadu za několik Sprintů. Nejsou ještě dostatečně malé ani úplně konkrétní, ale už mají obvykle formu User Story. Takových Super User Stories by mělo být připraveno na 5-10 sprintů. A zbývající čas Backlog Groomingu věnuje Product Owner konkrétním User Stories na vrcholu Backlogu. Ty už musí být INVEST, tedy jasné, konkrétní a dostatečně malé, aby se daly kdykoliv naplánovat a v rámci Sprintu dokončit. Takových User Stories potřebujeme v Backlogu na cca 2-3 Sprinty.
Backlog Grooming

Každý další Grooming už většinou Product Owner spolu s týmem prochází User Story podle priorit tak, aby měli pokaždé připraveno dostatek práce pro další Sprinty. Grooming se obvykle dělá v půlce Sprintu, aby v případě potřeby bylo dost času si danou funkcionalitu promyslet a to jak ze strany Product Ownera, tak týmu. Obvyklou součástí Backlog Groomingu je i ohodnocení User Stories Story Pointy, aby se Product Owner mohl rozhodnout na základě komplexity o prioritě, tým si ověřil, že to všichni chápou stejně a společně ev. dodefinovali akceptační kritéria, či User Story rozdělili.
Jak dlouho takový Backlog Grooming trvá? To záleží na přípravě, kterou tým jednotlivým User Stories věnuje, na připravenosti a kvalitě jednotlivých User Stories, a schopnosti efektivně komunikovat. První Groomingy obecně trvají dlouho, další mohou běžně trvat kolem 30-60minut.

Backlog Grooming

Chcete-li Grooming krátký, a navíc nemáte rádi meetingy, můžete zvážit jako tým na fotce ho dělat u tabule ve stoje. Určitě se omezí dlouhé nikam nevedoucí diskuse a posílí příprava týmu. Zároveň fyzická reprezentace umožňuje se zapojit do dodefinování User Stories každému, a nečekáte na Product Ownera až to dopíše do systému. Takže rozhodně doporučuju. Určitě to zkuste.

Jsou odhady zbytečné? #NoEstimates

Poslední dobou začíná být hodně populární neodhadovat User Stories. Proč? No když je umíte dobře definovat, stačí spočítat počet User Stories za Sprint a máte velocity. Bez dlouhých diskusí o bodech. Umožňuje vám to jak plánovat reálné množství práce, tak předvídatelnost v rámci produktu. Ono na tom něco je, když totiž umíte dobře definovat User Stories, tak to opravdu stačí. Ale… Co když neumíte, a teprve začínáte se Scrumem, nebo Agilem experimentovat? Jste zvyklí na mandays a hodiny, místo User Stories máte klasické requirementy? Pak je tato praktika téměř nereálná. Relativní jednotky – body – vám totiž pomáhají se spoustou věcí. A to číslo je překvapivě jen vedlejším produktem. Není samo o sobě důležité. Takže proč odhadujeme v bodech? Pomáhá nám to soustředit se na hodnotu pro zákazníka a ne na technické komponenty. Pomáhá nám to zvolit takové řešení, abychom co nejsnadněji dosáhli business cíle. Pomáhá nám to učit se komunikovat napříč departmenty (development, testing, business), a všechna ta diskuse, kterou okolo funkcionalit vedeme, z nás dělá dobrý tým. Učíme se dobře definovat funkcionality tak, aby tomu tým rozuměl. Diskuse okolo ohodnocení nám také pomáhají prioritizovat jednotlivé funkcionality. Ze začátku jsou nekonečně dlouhé. Tak byste radši vzali zkratku a než se naučíte chodit, jezdit na kole, lyžích, bruslích byste raději začali rovnou řídit auto nebo pilotovat letadlo. Teoreticky to možné je, ale v praxi takové zkratky moc nefungují. Takže jestli už nejen děláte Agile, ale jste opravdu Agilní, rozumíte Agilnímu mindsetu, máte pravý samoorganizující Scrum tým, tak je možná na čase to zkusit.

Jestli chcete vědět víc, ráda vás pozvu na konferenci Agile Prague 2014, 15.-16. září, kde o tom bude mluvit Vasco Duarte ve své přednášce “How to improve software project estimates – The #NoEstimates view“.

Jaké to je když vám vyjde kniha

První pocit? Překvapení. Přijde tlustý balíček se třemi autorskými výtisky. Jen tak, z ničeho nic. Jeeeee už je to tady! Ta je pěkná 🙂 a pak se vám začne honit hlavou, jak to celé bylo. Já v podstatě knihu psala v nejrůznějších koutech světa. Doma prostě nebyl čas se zastavit a přemýšlet. Proto tak ráda cestuju. Je to osvěžující. Kde to celé začalo? Já myslím, že v Indii. Seděli jsme u bazénu při konferenci a říkali si, že by bylo fajn napsat knihu. A vymysleli osnovu. A pak osnova pak dlouho ležela u ledu… A pak jsme začali pomalu psát. Kousek po kousku. Ale jak říkám doma mi to moc nešlo. Psát knihu je děsně práce. Trvá to nekonečně dlouho. Pořád to není hotové.

A tak jsem se rozhodla s tím pohnout a první rozumně velký kus jsem napsala v Indonésii. Bangka Island. Každý den po odpoledním ponoru, až do večeře. Jsou tam úžasné soft korály. Jedny z nejhezčích na světě. To je stejně můj sen, pracovat někde pod palmičkou. Pak bylo po dovolené. Pak další části vznikaly v letadlech a při čekání na letištích do Kalifornie – v San Fransicsu je úžasně, taky je tam moře. Pak cestou do Kieva, Rigy, Barcelony, Talinu, Kodaně, Krakova, Moskvy, New Yorku, v Las Vegas – nic jsem v casinech nevyhrála. Škoda, pár miliónů by se mi ke splnění snu sedět pod palmičku hodilo.

Další velký kus jsem napsala na Filipínách. Zase potápění. Odpolední dvě hodinky po ponorech na Moalboalu, pak v thajské restauraci na pláži v Boholu a finální části v Coronu, kde mají Japonské vraky plné podmořského života. Nádhera. Ale pořád to tak nějak nebylo hotové. Už mi to začínalo vadit, nemám ráda dlouho nekonečnou práci… a tak jsem poslední kusy dopsala ve Vietnamu v Saigonu nebo Ho Chi Minh City chcete-li. Hodina taxíkem do práce, hodina zpět do hotelu. Tam jsem ve finále četla i celou knihu ještě jednou v rámci finálního review. To si teprve uvědomíte, kolik jste toho napsali. To už bylo povzbudivé. Skoro hotovo. A jsem moc ráda, že jsem na knihu nebyla sama. Vždycky je daleko větší zábava s někým spolupracovat.

A pak nastal ten největší problém, kde sehnat vydavatele. Nakonec to šlo celkem snadno. A tak děkujeme nakladatelství Computer Press za vydání naší knihy “Agilní metody řízení projektů“ a doufáme, že se vám bude líbit. Co se dočtete?

„Snažili jsme se čtivou formou popsat všechna možná zákoutí a nástrahy, které vás při přechodu na Agilní metody mohou potkat. Kniha nepopisuje jen teorii, co to Agilní metody jsou, jak funguje Scrum Proces a Kanban, a jak by jednotlivé artefakty těchto procesů měly správně vypadat, ale primárně se snaží vysvětlit filozofii Agilního přístupu a zaměřit se na vysvětlení, proč jednotlivé metody fungují. Součástí textu jsou praktické příklady a doporučení co dělat a čeho se naopak vyvarovat.

Kniha se zabývá Agilními metodikami vývoje software v různých typech společností, od malých firem až po nadnárodní korporace. V první části knihy jsou popsány základní stavební prvky Agilního vývoje, od vlastní definice procesu až po ukázky z praxe. Čtenář se dozví všechny potřebné informace k adopci Agilních metodik, kulturní odlišnosti Agilních firem a další základní stavební kameny nutné pro úspěšnou adopci Agilních principů. Kniha dále obsahuje podrobný popis rolí, které se typicky vyskytují v Agilně řízených firmách. Vedle těchto popisů obsahuje kniha i “kuchařky”, resp. doporučené postupy adopce agilního řízení pro různé velikosti a typy firem.“

Dejte nám prosím vědět, jak se vám kniha líbila, co vás zaujalo, nebo co byste viděli příště raději jinak. Hezké čtení. Naší knihu Agilní metody řízení projektů můžete získat zde.

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.

Role testera v agilním týmu

Jedním z nejčastějších problémů, na které týmy při agilní transformaci narazí, je rozdílné vnímání rolí. V tradičním světě analytik dělá dopředu analýzu, vývojář to podle ní nakóduje a tester následně hledá chyby. O tom, že analýzy dopředu nepotřebujeme, neboť můžou vznikat klidně za běhu, se mluví často. O tom, že vývojáři mohou pomoci s testováním taky, ač tato praktika již obvykle není přijímána s takovým nadšením a slýcháme k ní spousty výmluv typu vývojáři to nemůžou testovat protože to neumí. No proto také říkáme, že testerům s testováním mohou pomoct. Ne že je mají nahradit. Hned druhá výmluva v pořadí je, že berou větší plat než testeři a tak že by se to nevyplatilo. A tak nám tato spolupráce obvykle zpočátku trochu skřípe.

Dříve nebo později tak týmy dojdou do stavu, kdy testeři na začátku Sprintu nemají co dělat a na konci nestíhají. User Stories jsou hotové – tedy nakódované – a přesto je nesmíme uznat jako výsledek Sprintu. Chybí přeci testy. Týmy v takové situaci přichází s různými legračními nápady jako např. že by bylo potřeba testery od týmu oddělit a udělat jim separátní posunutý Sprint. Tedy to, co vývojáři v jednom Sprintu napíšou, testeři v druhem Sprintu otestují a je to. Ale to jsme pořád mentálně ve waterfallu. Nikam blíže k agilnímu Scrum týmu jsme se v pochopení ani implementaci neposunuli. Bez ohledu na to, jestli máme tabuli a děláme standupy.

Jak by tedy taková spolupráce měla vypadat? Analytik, vývojář a tester si vezmou User Story, a začnou si o ní povídat. Analytik vymýšlí, jak by se daná funkcionalita měla chovat, vývojář to hned implementuje a tester upozorňuje, na co vše si musí dát pozor. Co uděláte když nepřijdou data? Co když nebudou validní? Nezapomeňte, že v akceptačních kriteriích je i to či ono. A v neposlední řadě připomíná business value (proč) definovanou v poslední části formule User Story, abychom v plném zapojení do implementace funkcionality nezapomněli, proč to vlastně celé děláme a v návrhu to zohlednili. Tedy v podstatě místo aby chyby chytal na konci (kdy už je pozdě), chceme aby chybám předcházel. Chceme, aby chyby vůbec nevznikaly a vývojář se tedy nemusel k již ‘hotovému’ kódu vracet. Spolu s tím, že testera zapojíme do návrhu řešení funkcionalit, chceme, aby vývojářům pomáhal již v průběhu a testoval jednotlivé části. V některých případech pak klidně pracují v páru, jinde jde jen o úzkou spolupráci. Honí-li se vám hlavou, že to nebude efektivní, protože tester to musí testovat pořád dokola, není tomu tak. Opravy chyb se také testují dokola a k tomu tam máme ještě multitasking vývojářů a jejich čas strávený opravou již hotových funkčností. A říkáte-li si, že to vaši testeři nezvládnou, protože co mají testovat pochopí až z hotové funkcionality, zkuste se podívat na to, jak dobře definované User Story máte. Jestli dobře, včetně akceptačních kriterií, je to snadné. Když ne, není to chyba testerů, ale pravděpodobně tomu nerozumí ani ostatní členové týmu.

Takže summary na závěr. Úkolem testera není chyby hledat, ale předcházet jim. Dobrý tester v agilním týmu dosáhne toho, že ve finálním testování User Story se žádné chyby nenajdou. A tím jen tak mimochodem ušetří firmě spousty času potažmo peněz. Dobrý tester rozumí zákazníkovi a funkcionalitě a pomáhá s návrhem řešení. Umí se na User Story podívat očima uživatele. Je to plnoprávný člen týmu, který je pro jeho úspěch klíčový. A otázka na závěr… Opravdu si myslíte, že takový člen týmu má mít menší plat jen kvůli názvu jeho pozice?

Agile Coaching ve Vietnamu

Není nad to spojit zábavu a práci. To dělám už několik let. Ale plně se mi to podařilo až teď, kdy jsem dostala šanci strávit dva týdny s týmy v Saigonu. První překvapení bylo, hned jak jsem ještě před odletem napsala na Facebook Agile Vietnam. Hned několik lidí odpovědělo v podstatě do minuty. Na tak aktivní skupinu člověk obvykle nenarazí. Např. na odpověď z Filipín čekám dodnes. Další překvapení byl Saigon. Pocit jak z Bangkoku před deseti lety. Takže i po této stránce příjemné překvapení. A to nemluvím o širokém výběru jídel, což se třeba o Indonésii tolik říct nedá.

Komunita

A abych se nenudila, domluvila jsem si hned na sobotu po příletu večer sraz s místními. Že si chtějí povídat o startupu. Byla to taková nesourodá skupina lidí, co by se chtěli dostat někam dál, scházejí se takhle každý týden. Asi čtyři z nich byli schopni konverzace v angličtině, zbytku to obvykle organizátor překládal. Z tónu řeči často nešlo ani poznat v jakém jazyce zrovna mluví. A to jsem si říkala, že mě mé cestování vycvičilo. Tak kupříkladu než mi došlo co je to “bilbo“ trvalo mi to docela dlouho… a ejhle, ve výslovnosti organizátora to znamenalo “people“. No dvě hodiny jsem zvládla, schopnost porozumět si se lepšila, a tak jsem cestou zpět už byla i schopna konverzovat se slečnou co mě vezla na motorce do hotelu. No legrace. Říkala jsem si, že jestli takhle budou mluvit a rozumět mé týmy, tak to že tedy nevím.

V neděli byl Barcamp. Monstr akce. 3600 registrovaných někde na universitě. Taková unconference. Ráno přijdete, registrujete se, a kdo chce, vypíše přednášku. A lidé hlasují, na kterou by rádi přišli. A prvních asi 60 přednášek dostane přiřazené místnosti a časy a celá akce se rozběhne. Téma zcela libovolné. Já mluvila o agilních metodách a jejich aplikaci ve firmách, co funguje a na co si dát naopak pozor, jedna Britka o tom že se chystají na podzim přivést Broadway show do Saigonu a jak to bude úžasné představení. Positivní na tom bylo, že úroveň angličtiny stoupla a tak jsem si i s několika návštěvníky popovídala.

Office

Office je daleko za městem. Asi 50 min taxíkem. Nic moc. Alespoň mám čas psát blog. Podle názvu by člověk očekával Pražský Chodov Park. Ale to jsem se asi zmýlila. Moc fancy to zvenku nevypadá. Kolem prázdné stavební parcely a naproti staveniště. Před pár lety tu asi měl někdo velké plány. Ostraha dole v budově se usmívá, ale ani slovo anglicky neumí. Nu což, naložila mě do výtahu, kde se mě ujali dva zaměstnanci a vzali mě na recepci. Recepční taky moc angličtiny nepobrala, ale naštěstí od té doby se to už jen zlepšuje. Týmy mluví na Vietnam vysloveně dobře. Naštěstí. Jinak nevím, jak bychom si ten agile vysvětlovali. A den začíná. Představení, Standupy, Backlog, prostě jako jakýkoli jiný tým. Tedy zdánlivě. Trochu působí dojmem, že to co se řekne, udělají a ještě to pochválí. Alespoň někteří. Ani nevím, jestli jim mám věřit, že se jim to opravdu líbí nebo ne. Asi tak napůl. Na druhou stranu je příjemné, že po dlouhé době nenarážím na v Čechách tak obvyklý odpor typu a to nejde, protože my jsme taková a onaká firma. Takže fajn. Opravdu to zkouší. Na druhou stranu, to co v Čechách je naprosto jasná výmluva, tady je i uvěřitelné. Že totiž oni opravdu nevědí jak. Takže asi potřebují pro začátek daleko detailnější rady jak to dělat a proč, včetně velice konkrétních detailních příkladů na každou situaci. Výrazně vyšší úroveň detailu.

Taky jsou občas pomalejší. Řeknete, co mají udělat, nic. Zeptáte se, jestli tomu rozumí, jo rozumí. Počkáte. Když se nic neděje, zeptáte se, jestli potřebují nějaké další informace, a když ne, zase je po chvíli pobídnete, aby to udělali. A pak, najednou z ničeho nic, se ty věci začnou dít. Zapojí se celý tým a dělají to, co jsme chtěli. Asi za tím stojí i jazyková bariéra, ne všichni třeba úplně rozumí. Příkladem byl třeba první rozpad jednotlivých User Stories na tasky. Nakonec jim to šlo. Tak já prostě nevím. Třeba na něco čekali, ale na co, to ví jen oni sami. A někdy taky ne. Ano, zítra přijdu na standup. Ano, rozumím tomu. Jojo. Zítra ráno. A ráno? No já nevěděl, že tam mám jít. Takže ještě jednou.
Obecně se dá říct, že většině z nich chybí nějaký nadhled. Logické uvažování. Když mám task, co obsahuje A a B a je moc velký,  řekli jsme ,že ho rozdělíme. A co se stane? Škrtne se B a zůstane jen A. Takže i rozdělení jedné věci na dvě je někdy náročný úkol. Vše se musí detailně ukazovat na příkladech a vysvětlovat. Ukazovat. Ale když už to pochopí, je spoleh na to, že to budou tak dělat. Jen to pochopení je často náročné. Asi je to příjemnější než typický český boj proti čemukoli novému. Taky se občas bránili, ale síla takového protestu byla výrazně nižší. Příčinou toho všeho je určitě i schopnost porozumět angličtině, vyjádřit efektivně myšlenku v cizím jazyce. Pochopit, o čem mluvíme. Ostatně občas z obou stran. Ale těch pár výrazů se za chvíli naučíte. Tak například “ktm“ popřípadě “ktmizšn“ je customer a customization. A taky ta změna co po nich s agilními metodami chceme je pro ně výrazně větší. Ale kdo ví. Prostě je to legrace.

Když se zamyslím, co bylo nejtěžší, tak pochopení agilní kultury, vstřebání agilního mindsetu. Oni do teď jeli striktní hierarchií. Kdo komu reportuje. A teď najednou máme Scrum a tam se SM nereportuje?? A kdo ty lidi tedy řídí? Nebo jiný příklad. Nakreslíte někoho do týmu s architekty a on najednou přestane pracovat v týmu a jen rozděluje práci. A když se zeptáte proč, tak on je přeci architekt, tak přeci nebude dělat běžnou práci, kterou zvládne kde kdo, no to je snad jasný, ne? Je to pod jeho úroveň. Tohle změnit bude trvat asi hodně dlouho. Ale i za dva týdny se hodně lepšili a mnohé začalo fungovat jinak. Jsou šikovní. A hlavně třeba například na rozdíl od Indů mají velmi positivní přístup. Chtějí, snaží se, neschovávají se za procesy. Nevymlouvají se.

Dalším místním koloritem je, že ve 12:00 zhasnou, a v těch svých kancelářských židlích se uloží na hodinu k spánku. Někteří s takovou tou škraboškou na oči, jako se dává v letadlech. Některé jsem po pauze musela budit v zasedačce na stole. Někdy prý spí i v chodbě na zemi. No jiný kraj…

A výsledek, za dva týdny porozuměli Scrumu, naučili se definovat na základě highlevel požadavků PO jasné a konkrétní User Stories, mají výstavní tabuli a hodně zapracovali na kvalitě výstupu Sprintu. A dokonce byli schopni udělat pěknou retrospektivu. Teď už to jen udržet. Ale to oni zvládnou.

Starting Scrum Workshop

Někdy v polovině mého pobytu v Saigonu jsme spolu s místní agilní komunitou naplánovali odpolední free workshop Starting Scrum. První problém byl, jestli seženeme marshmallow. A po chvíli hledání v supermarketu se to podařilo. Globalizace doveze všechno všude. Špagety už takovým problémem nebyly. Tak nezbývalo než počkat, jestli hru pochopí a jestli se jim bude líbit. Dorazilo asi 55 lidí. Zdaleka ne všichni byli ze světa sw vývoje. Část tvořili místní expati kteří vítají každou příležitost se potkat, popovídat si anglicky a něco nového se dozvědět. Většina ale místní. Byli tam Scrum Masteři z firem co Scrum aplikovali, ale i lidi, co o tom do teď neslyšeli. Pět týmů, relativně volné zadání, postavte vysokou věž. Po každé iteraci demo. Bylo super, že to zvládli. A stejně jako kterýkoli tým kdekoli na světě se každou iterací zlepšovali. Na závěr jsme dělali retrospektivu a příjemným překvapením bylo, že se na tomto cvičení hodně naučili. Sami si přišli na to, co bylo potřeba. Hry tedy fungují kdekoliv, což je určitě dobré zjištění.

Na závěr

Docela se mi práce v Asii zalíbila. Vždycky se mi tu líbilo, ale dokud tu člověk nemá práci, tak nevíte. Takže jestli máte nějaké týmy ve světě, a chcete je rychle naučit agile, ozvěte se 🙂

Jak vypadá Scrum Board

Minule jsem slíbila, že příště poradím, jak by měl vypadat správný Scrum Board, tedy Scrumová tabule. Nic složitého. Základ je, že použít můžete úplně cokoliv. Tabuli, stěnu, skříň, sklo. Nic sofistikovaného. Stačí tři sloupce: Sprint Backlog, In Progress, Done. Tedy to co máte dělat, na čem zrovna pracujete a co už je dokončené. Více sloupců je kontraproduktivní a často v psychologické rovině naopak omezuje týmovou spolupráci. Začínající týmy často používají místo in progress sloupce jako code, test, review, apod. Tím se však jen zuby nehty snaží držet toho, jak pracovaly před agilem. Pochopitelné, ale o moc dál nás to neposune.

Z tabule by mělo být i koutkem oka pro náhodné kolemjdoucí vidět
– jestli tým stihne práci dokončit nebo ne,
– kdo na čem zrovna pracuje,
– a co konkrétně ještě zbývá k dokončení jednotlivých User Stories.

Jestli vám něco z toho chybí, změňte to. Když máte tabuli na papíru, je to snadné a jakákoli změna nezabere víc než pár minut. Můžete argumentovat, že je lepší mít nástroj, ale to pro tabuli rozhodně neplatí.

* Tým se podle takové tabule orientuje, všichni by se v ní tedy měli vyznat. Použít můžete různé barvy pro různé typy aktivit, červeně zvýraznit blokace, klidně i se jménem, na koho že to čekáme.
* Ideální je organizovat User Stories do řádek tak, aby bylo vidět kolik tásků je již hotovo, kolik je rozpracováno a kolik zbývá dokončit.
* Udělejte si pro jednotlivé členy týmu avatara (ideálně jednoho, protože stejně chcete limitovat work in progress a jeden člověk by tak mohl pracovat jen na jednom tásku), ať na první pohled vidíme, kdo na čem zrovna pracuje.

A tady je pár fotek tabulí, které můžu doporučit pro inspiraci:

Kreativitě se meze nekladou :),  je to jen na vás. Takže se můžete podívat, jak v týmech vypadají další tabule. Ne všichni tady dodržují výše popsané principy, ale i tak mohou být dobrým zdrojem inspirace.

A na závěr, na tabuli můžete mít klidně celý Backlog, jako měl jeden krásný startup sídlící v samém srdci NYC. Ti byli opravdu agilní. Celou duší. Vlastně jsem nikdy neviděla lepší agilní kulturu. Tam bych jednou chtěla pracovat 🙂

Proč je Sprint Burndown omyl

Slíbila jsem vysvětlení, proč je Sprint Burndown zbytečným overheadem a co dělat namísto něj. Tedy začněme tím, co by mělo být cílem – a tedy poznat, jestli tým ještě stihne dokončit User Stories, ke kterým se v rámci Sprintu zavázal. Tedy všechno, co je ve Sprint Backlogu. A to co nejjednodušší cestou. Bez zbytečných věcí. Když jsem nad tím přemýšlela, došla jsem k závěru, že většina lidí Sprint Burndown používá prostě proto, že nástroj který si koupili ho umí vykreslit. Tedy upřednostňují nástroje a procesy před lidmi a vztahy mezi nimi. Hned první věta agilního manifestu 🙂
Ale řekněme, že tohle není váš případ, že byste opravdu jen rádi věděli, jestli tým Sprint Backlog dokončí včas. A tak jste si začali takový graf kreslit ručně. A ejhle. Jak takový graf obvykle vypadá? No třeba takhle. Tým pracuje na mnoha User Stories najednou, a než dokončí první, je tu konec Sprintu. A když se Scrum Master v polovině Sprintu zeptá, jestli stihneme všechny User Stories ze Sprint Backlogu, dostane se mu obecného ujištění ve stylu “no jasně”. Nicméně z výše zmíněného Burndown Grafu to vidět není.

Možná namítnete, že váš tým přeci jen něco v průběhu dokončí, pak situace vypadá asi tak takto… ale to v reálu na věci nic nemění. Nezbývá než si držet palce. Nic o výsledku nám takový graf neříká. Jen ukazuje na fakt, že nic nevíme.

A někde tady se rodí myšlenka implementovaná mnoha nástroji, že je pro Burndown graf třeba trackovat jednotlivé úlohy. A abychom měli přehled, začneme je ohodnocovat v čase. Ale pozor, není čas přesně to, čeho jsme se v rámci agilních přístupů snažili zbavit? Na co pak ohodnocujeme v bodech, když tým vzápětí vracíme do světa man-days a hodin? Odhlédneme-li od toho, že založit úlohu v systému stojí nemalý čas týmu, který se členové týmu snaží minimalizovat tak, že zakládají relativně velké úlohy, aby je pak nemuseli měnit, nebo dokonce zahodit. A tyto pak odhadují v hodinách a své odhady kolik času zbývá, každý den mění. A překvapivě, jsme na tom obvykle ještě hůř, než bez takových odhadů. Většinu času si myslíme, že je všechno v pohodě, a ejhle, ono nebylo. Může za to mnoho faktorů, psychologie a optimismus vývojářů či testerů je jedním z nich. Už je to přeci skoro hotové.

No a teď už zbývá jen jeden krok – tedy místo nějakých odhadů prostě jen měřit čas, který jsme na daných User Stories strávili, a ten v grafu zobrazit. A světe div se, dostaneme každý Sprint krásnou lineární křivku, kolik “hodnoty“ tým každý den vyprodukoval. O tom, kdy to bude hotové, takový graf neříká nic, ale zato pěkně vypadá, dá se hezky reportovat a tým může všem dokázat, že poctivě pracoval.
Takže co s tím? Daleko snazší metodou jak zjistit, jestli ještě stihneme dané User Story dokončit, je udělat dobrou a přehlednou Scrum tabuli. Tři sloupce – backlog, in progress, done. Přehledně označit, kdo na čem pracuje, a co je ještě třeba dokončit. Dodržovat best practice tak, že limitujeme work in progress, tedy rozpracovanou práci, snažíme se věci rychle dokončovat a aby to bylo pěkně vidět, rozpadnout User Stories na jednotlivé činnosti o velikosti cca jeden den. Přidat lístek s taskem trvá několik vteřin, zahození ještě méně. Je to snadné, rychlé, efektivní. I náhodný kolemjdoucí koutkem oka z takové tabule vidí, v jakém je to stavu. A to se může hodit. Ušetříte si kupříkladu otravné otázky Product Ownera, jestli to stihnete, ale hlavně, budete sami vědět, na čem opravdu jste. A abych vás nenechala bez návodu, o tabuli, jak ji používat, a jak má vypadat, napíšu zase příště.