Category: Scrum

Vše o Scrum procesu

Správný Product Owner není úředník

Správný Product Owner má nápad, dokáže ho zformulovat do vize, a tu prodat jak zákazníkům, tak firmě i týmu, který pro něj pracuje. Spousta Product Ownerů ale je jen úředníky. Vychází z té armády business requirement specialistů, business konzultantů. Dělají to, co jim někdo řekne. To se ale přesně snažíme pomocí Agilních metod a Scrumu změnit. Proto jsme toho člověka udělali Product Ownerem, a ne jen Product úředníkem.

Jak takový produkt začíná? Ideálně si uděláme product charter. A to jak pro produkt jako takový, tak pro první release. Co to je a jaký to má formát. Je to snadné. Vše se vejde na jeden flipchart. Jméno, timeframe, elevator pitch – tedy jedna, dvě věty, které shrnují, co že to děláme a hlavně proč, vytváří obrázek, konkrétní jasnou představu cíle, vzbuzují emoce. Prostě vás zaujmou. A pak ve dvou sloupcích jako stručné odrážky cíle, kterých chcete dosáhnout a success measures, tedy jak poznáte, že jste toho dosáhli.

Product nebo Release Charter je klíčová věc. Bez ní ani nemá smysl se pouštět do psaní Backlogu a User Stories. A není to ani snadné. Když se do toho pustíte, bez ohledu na množství prezentací, které jste už o produktu vyrobili, zjistíte, že umět z toho všeho, co byste mohli dělat vydestilovat podstatu stojí čas a energii. A Product nebo Release Charter je přesně to, co vám roli Product Ownera jako člověka zodpovědného za funkcionalitu (tedy Backlog) a celkový úspěch produktu usnadní. Cílem toho “product úředníka“ z klasického světa totiž je daný nápad rozpracovat do šířky. Vymyslet co nejvíce funkcionality tak, abychom pokryli přání zákazníků a stakeholderů. Cílem Product Ownera ale je pravý opak. Nápady a přání omezit na minimální funkcionalitu, která zákazníkům přinese to, co opravdu potřebují. Dělat tedy ne to, co umíme a můžeme, ale jen to, co má nejvyšší business value. To, co potřebujeme. Jen takový produkt je potom agilní, a jen takový produkt bez ohledu na Agile a Scrum je úspěšný.

Jak vybrat Scrum Mastera aneb proč i zkušení Scrum Masteři selhávají v Agilní transformaci

Role Scrum Mastera není zdaleka snadná, a ne nadarmo se považuje za klíčovou k úspěchu týmu a nasazení Scrum procesu. Scrum Masterem je typově někdo jiný než se hodí na běžnou roli team leadera (který často vše určuje za tým), nebo experta (který se neptá, ale za tým rovnou odpovídá, protože jako expert zná vždy tu správnou odpověď), nebo projektového managera (který často mikromanaguje, vše řídí sám a to včetně organizace týmu, priorit a celé dodávky). Scrum Master není zodpovědný za dodání, ale za to, že tým funguje jako samoorganizovaný tým, že tým přebírá zodpovědnost za svůj vnitřní proces, že se zlepšuje, je motivovaný, prostě v dlouhodobém pohledu funguje optimálně. Krátkodobě klidně nechá tým v rámci Sprintu nedodat nic, ale nenechá takovou situaci vyrůst v běžný zvyk a obvyklý stav. Když máte plně Agilní firmu a zaběhnutý, zkušený tým, je to relativně snadné. Stačí najít Scrum Mastera, který rozumí Scrum procesu a podstatě své role, je vnímavý, empatický, umí naslouchat a dá týmu prostor, aby se sám rozhodoval a nesl v rámci procesu za svá rozhodnutí zodpovědnost. Koučuje, facilituje, staví tým. A tým funguje.

Problém nastává, když ale Scrum Mastera zvyklého takhle pracovat dáte do týmu, který ani neví, co je Scrum, proč jednotlivé praktiky aplikují a co by jim měly přinést. A takový Scrum Master si nevzpomene na své začátky, a jen pomocí coachingu a facilitace vykonává roli Scrum Mastera v ideálním týmu tak, jak byl zvyklý. To samozřejmě nestačí. Scrum Master musí být i mentorem a týmu Scrum proces vysvětlit, prodat. Ne přikázat, ale poradit. A postupně je učit Agilu jako mindsetu, Scrumu jako procesu, kde jde primárně o zodpovědnost, samoorganizaci. Čistý koučing a facilitace nestačí. Tým prostě neví co a jak. Nemá zkušenosti. Nikdy nic podobného nezažil.

Další častou chybou Scrum Mastera v začínajícím týmu (a takový tým může začínat i dva roky) je pocit, že tým musí ‘rychle začít fungovat a že vysvětlování ‘proč‘ by vše jen zdržovalo. Prostě jim řekne, jaké mají dělat meetingy a co na nich říkat, a žádným školením ani vysvětlováním proč to všechno se nebude zdržovat. Vždyť je to jasné. Výsledkem je v lepší případě technický Scrum. Bez pochopení, bez energie, bez výsledku. Takové loutkové divadlo. Kdo je za takový stav odpovědný? No zcela jistě nezkušený Scrum Master, který neupravil svůj styl týmu. Problém je, že na interview to často nepoznáte. Scrum Master ví, jaká je jeho role, co má dělat, ví proč a jak Scrum funguje, jen nepovažuje za nutné to týmu vysvětlit. Vždyť už agilní jsou, říkali to.

Dalším problémem, který je ve firmách častý, je Scrum Master idealista. Stejně jako v předchozích případech, na pohovoru vše vypadá dobře, ba ideálně. Scrum Master je pravým odborníkem na Scrum. Ví jak funguje, rozumí své roli, a v jednom dobře fungujícím týmu úspěšně Scrum Masteroval. Jen se často zapomene na to, že on ten Scrum neimplementoval a často ani nezažil v rámci větší organizace, a tedy se s mnoha problémy běžnými při transformaci velké organizace nikdy nesetkal. Stačilo rozumět Scrum procesu a mít nadšení. Ve velké organizaci ale nejde implementovat všechno hned a ideálně. Musíte dělat kompromisy. Zbytku organizace často trvá hodně dlouho, než Agilní proces vezme na vědomí a ještě déle, než ho akceptuje a pochopí. Předchází tomu hodně komunikace, diplomatického vyjednávání a PR. Ale Scrum Master idealista na nic nečeká a Scrum tlačí silou hlava nehlava. Product Owner musí, manager nesmí, tým neřekne, protože to není jeho zodpovědnost, proces se musí změnit, pozice upravit, ohodnocování změnit, … Výsledek je jak po procházce slona v porcelánu. Víc škody než užitku. A to nejen mimo tým ve zbytku organizace, ale i v rámci týmu, který takového Scrum Mastera často odmítne stejně jako v předchozích případech. Co z toho plyne? Transformaci velké organizace nemůžete nechat na lidech, co nikdy žádnou takovou organizaci neměnili a s podobnou transformací nemají zkušenosti. A to bez ohledu na to, jak dobrými se zdají být Scrum Mastery. Zdá se to být jasné, ale firmy si často roli Agilních coachů se Scrum Mastery pletou a pak jsou překvapení, že Scrum Master se neosvědčil.

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.

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ě.

Jak zabít Scrum

Najdete spousty článků jak být agilní, jak Scrum úspěšně nasadit… ale ve spoustě firem řeší naprosto opačný problém. Jak zabít Scrum. Dělám si trochu legraci, ale občas to tak vypadá.

Takže jak na to. A přidejte se s nápady a komentáři. Co dělat, aby to spolehlivě zabilo Scrum. Co napadne každého, je postavit silného šéfa co rozděluje práci a alokace a o všem musí rozhodnout. Najdete spoustu takových nápadů. Ty jsou zřejmé a jsou moc vidět navenek. Bijí do očí. Dá se proti nim bránit. Mám vypozorovnu lepší metodu jak nasadit Scrum bez toho, aniž bychom se museli bát, že se osvědčí. Je to snadné. Naučíte se pár pojmů. Scrum = to je náš nový proces, nebojte se, nic moc se tím nezmění. Sprint = to je jakési období, za které máme něco dokončit. Když to nestihneme, prodloužíme Sprint třeba na třičtvrtě roku. To by bylo, abychom to nestihli. Máme přeci komplexní produkt. Backlog = requirementy a usecasy. To máme, nemusíme tedy nic měnit. Business na nás stejně nemá čas. Nezajímá ho to. Tak se o Backlog stará armáda Business Analytiků. Mají toho moc, ale nakonec to rozmyslí dobře. Body = Divný. Mandays nám vyhovují, jsme na ně zvyklí, tak proč přeházet na body. Standup = to je taková pěkná praktika. Pojďme se každý den sejít a popovídat si. To se ve Scrumu dělá ne? Lidi alokujeme na plno projektů najednou, tak ať se jednou denně vidí. To bude stačit. Tým = skupina specialistů, co věří, že ostatní by v žádném případě nezvládli to, na čem oni pracují. Jsou přeci specialité – na danou oblast, nebo technologii, nebo oboje. Tak co bysme jako sdíleli a jak bysme si pomáhali, že..

Povědomé? Na zabití Scrumu stačí spolehlivě dvě věci. Začít používat názvy bez porozumění a obsahu. A podpořit to zdlouhavým pravidelným Stand-up meetingem bez závazku a bez týmové spolupráce. A věřte či ne, za pár týdnů ani největší optimista neuvěří že Scrum je pro vaši firmu vhodnou metodou.

Několik důvodů proč rozdělit User Story

Důvodů proč rozdělit UserStory může být hned několik.
Ten nejčastější je, že je moc velká a nevejde se do Sprintu. A protože základem Scrum procesu je pravidlo že tým vybere co během Sprintu dokončí a to na konci prezentuje zákazníkovi na customer demu, takovým UserStory které by dokončit nešly se musíme vyvarovat. Jak UserStory dělit? Po menších funkcionalitách. Nikdo neříká že takto rozdělěnou UserStory si zákazník musí nutně chtít koupit, ale jen že mu musí přinášet hodnotu. A ta je třeba i v tom, že si představí, co vlastně od dané funkčnosti chce. Tedy např. pakliže chce fakturace, asi si nekoupí jen readonly seznam faktur, ale bude je chtít i vytvářet a tisknout a filtrovat… ale jako mezivýsledek po prvním Sprintu mu hodnotu přinese i jen obyčejný seznam.

Druhým důvodem je různá priorita jednotlivých funkčních celků. Ono je to jedno spojeno s druhým. Když je UserStory moc velká, tak se obvykle Product Owner ptá, co jí dělá tak náročnou a komplexní. A přijde se obvykle na to, že udělat seznam faktur je snadné, ale tým ještě nikdy nedělal print preview a daná komponenta ho neumí a tedy je to pro ně náročné. Ono ale obvykle ne všechno je nutné a ne všechno stojí za tu cenu, kterou to má. A může se stát, že možnost print preview pro zákazníka vlastně nemá takovou priorotu a že ji odloží, na čas, či úplně.

Scrum vám umožňuje funkcionalitu řídit. Tím že složité celky musíte rozpadnout na menší kusy aby je tým stihnul v rámci Sprintu vás nutí přemýšlet o tom, jestli opravdu všechny drobné funkcionality potřebujete a jestli estimate odpovídá ceně, kterou jsme ochotni za očekávanou business value dané funkcionality v UserStory zaplatit.

Kdo píše User Story? A kdo tasky?

A jako pokračování v mém miniseriálu o agilních metodách, Scrum procesu a konkrétně User Stories je odpověď na otázku kdo píše User Story?

Tak jako obvykle, navrhnout User Story může kdokoliv. Libovolný člen týmu, vývojář, tester. Nicméně Scrum zavádí roli Product Ownera, který je za celý backlog a User Story v něm zodpovědný. A proto je Product Owner ten, kdo User Story nakonec do backlogu akceptuje, a přiřadí jí v závislosti na business value prioritu. Product Owner je tedy ve Scrumu často ten, co User Story definuje, následně je ale diskutuje jak s produktovým týmem tak se Scrum týmem který jednotlivé User Story ohodnocuje.

A kdy se mají jednotlivé User Story rozdělit na tasky/úlohy? Idealně během planningu, maximálně první den Sprintu. Když to uděláte později či vůbec, riskujete, že většina členů týmu nebude vědět, z čeho se jednotlivé User Story sestávají, co nám jako týmu ještě chybí dokončit a jak jsme daleko.

Co je task? Task neboli úloha je nějaká jednotlivost, která se musí udělat, aby User Story přinášela očekávanou hodnotu. Tedy pro User Story “jako manažer, chci mít evidenci zaměstnanců, abych měl rychlý přehled o všech lidech ve firmě i detailu konkrétních pracovníků.” to může být např. založení tabulky a číselníků, zobrazení dat z db na obrazovku v browsu, filtrace, zobrazení jedné detailní položky zaměstnance, grafický design obrazovek, test. Každá úloha by neměla být delší, než řekněme dva dny a kratší než půl den už je možná zbytečný detail, nicméně může mít smysl si i takovou úlohu zaznamenat, abychom na ni nezapomněli. V průměru by každá úloha měla být tak asi na den práce, což nám pak usnadňuje denní standup meeting, kde je pak snazší definovat, co opravdu dokončíme.

Na začátku jsme psala, že za User Story je zodpovědný Product Owner, potom za rozpad těchto User Story na tasky / úlohy je naopak zodpovědný tým a jsou tu jen pro interní potřeby týmu. Aby všichni věděli jak daleko ještě jsou od cíle a to i bez složitého ohodnocování jednotlivých úloh a kreslení Sprint Burndownu. Vše je pak na první pohled vidět z tabule – Scrum Boardu.