Tag: Scrum

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

Nástroje omezují a svazují

Než začnete diskutovat na téma, že nástroje jsou přece užitečné, podívejte se kolem sebe. Kolikrát jste slyšeli, že ten a ten systém je špatný? Že vám nedává to, co byste chtěli? Že musíte používat jeden a raději byste měli druhý? Že nemůžete věci dělat jinak, protože váš nástroj to neumožňuje? A čím větší je firma, tím více procesů a nástrojů vygenerovala. O procesech jsem psala minule, takže těm se pro tentokrát vyhnu. Vzpomínáte si na Agilní manifest? Hned první princip říká “Upřednostňujeme lidi a jejich vztahy před procesy a nástroji”. A přesně v tomto kontextu je to potřeba vnímat. Opravdu upřednostňujete to, co vaše týmy potřebují, před tím, co zrovna musíte používat za nástroj? Viděla jsem spoustu týmů, které implementovali Agile a Scrum tak, že začali hledat nástroj… Nástroj, který jim pomůže být agilní a Scrum nasadit. Ale to není zrovna agilní přístup, že?

Najdete různé pěkné nástroje, které umí mračna zajímavých věcí. A tak týmy, ve snaze využít maximum možností, dělají milióny věcí, které jim nic nepřinášejí a k opravdovému cíli – tedy společně dodat hodnotu pro zákazníka efektivně, rychle a kvalitně – nás nikterak neposouvá. Ba právě naopak. Jsme pak často pomalejší, Scrum se stává divnou byrokracií bez obsahu, a jako takový nepřináší vyšší zapojení jednotlivců, nadšení, ani žádné inovace, ale jen “my teď musíme… “, “my nemůžeme…”, a nebo “my pořád schůzujeme a vyplňujeme”…

Příkladem toho, o čem mluvím, může být třeba ohodnocování tásků hodinami. Výborná praktika, která žere neskutečně času týmu a jediným důvodem pro její vykonávání je to, že náš nástroj pak umí kreslit burndown graf za Sprint… Který však, podíváme-li se na něj čistýma očima, nepřináší nic, co bychom už dávno nevěděli z dobré tabule a funkčních standupů. Sprint burndown je naprostá zbytečnost, která se v agilní komunitě ujala právě proto, že týmy viděly další pěknou věc, kterou jejich nástroj umožňuje, tak proč ji nezkusit, že?

Dalším příkladem jsou různé nástroje, které umožňují vidět tabuli online. A teď ani tak nemluvím o geograficky distribuovaných týmech, ale o lidech, kteří sedí v jedné budově či dokonce místnosti… Na začátku za tím stojí dobrý nápad, my budeme naši tabuli vidět odkudkoliv, nemusíme vstávat, abychom tam udělali změnu… Ale není to náhodou přesně to, čeho se chceme vyvarovat? Co chceme agilním přístupem změnit? Vždyť my přece chceme, aby se tým potkával a povídal si, aby každý mohl vzít tužku a lísteček a hned napsat, co se musí ještě udělat, a když se něco změní, tak prostě lísteček vzít a zahodit, jako by ani neexistoval. Nepotřebujeme historii tásků popsanou do posledního detailu. Nepotřebujeme evidenci všech změn a nápadů, které jsme kdy měli… Chceme si jen být jisti, že jako tým ještě stihneme dokončit všechny User Stories které jsme zákazníkovi slíbili. A nechceme žádnou zbytečnou byrokracii. Zkuste si napsat task na lepítko anebo zadat do systému. První varianta je mnohonásobně kratší a všichni její výsledek vidí kdykoli vzhlédnou nebo jdou kolem na kafe, aniž by museli spustit systém a dát refresh.

A když volně přejdeme k dalšímu přikladu, chceme se flexibilně organizovat… Není tedy cílem vzít User Stories a na začátku Sprintu je přiřadit jednotlivým lidem. A mentálně je za ně udělat zodpovědnými. Tým by měl být za jejich dodání zodpovědný jako celek, ale když se řídíme nástrojem, tak to často nejde. Ano, některé týmy User Stories přiřadí Scrum Masterovi aby nástroji něco předhodili. Ale většina takových řešení funguje psychologicky na backgroundu a ovlivňuje – aniž byste si to uvědomovali – vaše chování. A to i ve věcech, kde byste se hádali do krve, že vás to přeci neovlivní. Že nevěříte? Dělaly se například studie s velkou skupinou lidí. První skupina dostala otázku “Kolik obyvatel má stát Texas?”. Když z odpovědí celé skupiny uděláte průměr, dostanete nějaké číslo. Druhá skupina dostala velmi podobnou otázku – “Kolik obyvatel má stát Texas, je to více než 500 tisíc?” a překvapivě odpovědi byly výrazně bližší číslu 500 tisíc. Experiment se v různých podobách opakoval mnohokrát a pokaždé se stejným výsledkem. Říká se tomu kotvení. A zpět k příkladu s nástrojem, který vás nutí User Story assignovat konkrétnímu členovi týmu. V momentě, kdy to uděláte, zakotvíte zodpovědnost z týmu jako celku k nějakému konkrétnímu členu týmu. A stejně jako u výše zmíněné otázky na obyvatele Texasu, na pozadí to ovlivní chování týmu. Aniž byste si to uvědomili. Je to psychologie chování lidí.

Scrum překvapivě drží pohromadě právě na tom, že jednotlivé praktiky různým způsobem podporují nebo naopak omezují jisté stereotypy chování lidí. Scrum je postaven na psychologii. Bez ní je to jen technický proces, který v praxi pouze vzbudí ohromná očekávání ale výsledek se nikdy nedostaví. Nástroje jsou fajn, ale bez toho, aniž rozumíte psychologii na pozadí Scrum procesu, bez toho aniž byste pochopili Scrum DNA, jsou většinou kontraproduktivní a Scrum a Agile zabíjejí. Velice rychle a chytře. Jsou jak rakovina, která se usídlila v organizmu týmu nebo firmy. Po chvíli se vy přizpůsobujete nástrojům, ne naopak, a to je přesně ta chyba. Používejte nástroje, protože tu jsou od toho aby vám pomáhaly, ale v momentě kdy zjistíte, že něco děláte jen proto, že to nástroj umožňuje, nebo že naopak něco neděláte, jen proto, že to nástroj neumožňuje, zastavte se a zamyslete se kdo má koho pod kontrolou. Vy nástroj, nebo nástroj vás. A v prostředí, ve kterém lidi a týmy řídí nástroje, se lidem moc nedaří.

Co když zákazníka zajímá jen termín dodání?

I tak můžete být v pohodě agilní a implementovat Scrum principy. Scrum není jen pro projekty, ve kterých je zákazník ochoten se stát aktivní součástí vašeho týmu. Scrum proces vás učí, jak si najít řešení na problémy které máte, sami v rámci vašeho týmu. Dobře fungující samoorganizující týmy nečekají, až jim někdo problém vyřeší, ale samy se ujmou iniciativy. V ruce máte Roli Product Ownera, Backlog, Burndown a schopnost bez obav a hlasitě upozorňovat na to, jaká je realita. A to jak obchodníkovi, tak managerům.

Pro příklad řekněme, že váš obchodník domluvil se zákazníkem dodávku informačního systému, aniž by cokoliv konzultoval s týmem, od zákazníka přišlo velice vágní zadání a tým vlastně neví, co má dělat. Obchodník navíc slíbil dodání systému za 3 měsíce a na straně zákazníka se nikdo netváří, že by chtěl s týmem jakkoli komunikovat. Nasnadě je potom zatažení obchodníka do týmu a prezentování funkcionality jemu, protože v reálu on je zákazníkem týmu, a protože je zároveň zaměstnancem firmy, měl by v tomto kontextu hrát roli Product Ownera a riziko úspěchu vzít na sebe. Jak ho přesvědčit? Tak například, že to je pěkné, že ty jako obchodník chceš všechno tohle do května, ale my jako tým jsme měli za poslední Sprinty rychlost 20 a tedy stihneme do daného termínu jen přibližně polovinu zadané funkcionality. A buď budeme pracovat jako tým, a dodáme zákazníkovi maximální hodnotu, nebo ty funkce vezmeme např. podle abecedy. A v květnu se stejně ukáže, že jsme to nestihli, a on se ten projekt nějak už prodlouží, jako vždycky. I když se mu ze začátku nechce, tým by měl pokračovat ve zvaní jeho i ostatních managerů firmy na Sprint Review a neustále upozorňovat na vzniklý problém. Asi to není příjemné, ale bývá to pro firmu lepší než čekat, až se na to na konci přijde. Problém, o kterém víte včas, můžete řešit. A od toho manažeři ve firmách jsou.

Pakliže z nějakého důvodu není vhodné z toho, kdo obchod domluvil udělat Product Ownera, tým ze svého středu postaví v roli Product Ownera někoho jiného. Už jen tím, že taková role vznikne, se často hodně změní. Najednou to nejsou jen vývojáři a testeři, kdo si stěžují, ale někdo v roli Product Ownera, kdo má na starosti primárně blaho zákazníka a business value. Cílem Product Ownera v takovém projektu je co nejrychleji získat background a pochopit kontext, který potřebuje pro řízení funkcionality pro daného zákazníka. V ideálním případě takový Product Owner naváže se zákazníkem vazbu a po čase je schopen od něj na neformálních setkáních potřebnou zpětnou vazbu získat. Je to o dobré komunikaci, schopnosti dobře naslouchat a vyjednávat.

V lepším případě máte sice Product Ownera, ale ten je od týmu daleko, někdy oddělen časovou zónou, někdy jen kontextem, a na nic jiného než termín dodání mu čas nezbývá. Takové týmy potom staví někoho v roli Product Owner Proxy, což je člověk s technickým backgroundem, který ale rozumí business pohledu a je schopen vzniklou díru mezi Product Ownerem a týmem vyplnit. Na globálních projektech s virtuálními distribuovanými týmy je to obvyklé řešení.

Ať již máte u vás podobné případy nebo ne, Agile a Scrum identifikuje problémy včas, a tak i kdyby to, že nestíháte nikdo zákazníkovi říci nechtěl, a jednání o změně kontraktu bylo příliš rizikové, pořád je lepší o problému vědět a mít možnost se rozhodnout, co s takovým projektem budeme dělat. Agile nám dává pomocí transparentní komunikace a jiného systému práce a odhadů velice relevantní informace o tom, co je tým schopen, v jaké kvalitě a rychlosti dodat.

Jak vypadá Scrum, jak Scrum Master, jak má Scrum Master motivovat tým a jak řídit produkt

Jsou to zdánlivě nesourodé otázky, ale dalo by se říct, že po shlédnutí příslušných videí budete vědět, jak vlastně agilní metody fungují.

Jak vypadá Scrum?

Začneme krátkým úvodem Scrum ve 13s.

Že jste se toho moc nedozvěděli? Pusťte si video ještě jednou, a zjistíte že Scrum je iterativní proces, v každém cyklu dodává nějakou část, která má hodnotu. Zjistíte, že existuje něco jako Product Backlog, ze kterého se před každou iterací vybere pár celků, které tým v jednotlivých dnech zpracovává a které na konci iterace dodá jako hotové a nasaditelné. Na dokončené kousky se dívají ti, co k produktu mají co říct, tedy zákazníci, business, uživatelé a z jejich zpětné vazby vznikají požadavky na změnu, nové funkcionality, či funkce které můžeme oželet a ty se hned promítají do Product Backlogu. To je na 13s vaší pozornosti informací až až.

Kdo je to Scrum Master a jak spolupracuje s týmem?

Video má tentokrát asi 5min a uvidíte v něm jak se Ian jako “Super Scrum Master“ stará o svůj tým. Že byste to dělali jinak? Proč ne. Podstata je ale stejná. Všichni včas na Standup, nerušit tým změnou priorit, dodržovat done kritéria, brát testování jako součást úlohy. Scrum Master musí dělat to co je potřeba. Je coach a facilitátor. Je to o týmu. Ne o Scrum Masterovi. Ale bez dobrého Scrum Mastera nikdy nebudete mít dobrý tým.

Jak má Scrum Master motivovat tým?

A jak je téma složitější, prodlužuje se délka videí. Tohle je na přibližně 20min, ale opravdu stojí za zhlédnutí do konce. Přesně takhle totiž funguje motivace. Italy Talgam demonstruje na ukázkách různých dirigentů a orchestrů jak funguje leadership. Ve kterém orchestru byste chtěli pracovat? A který dirigent by byl dobrým Scrum Masterem? To určitě posoudíte sami.

Jak řídit produkt?

Poslední video je nejdelší, ale také je více nabito informacemi. Vytvořil ho Henryk Kniberg a myslím, že stejně jako jeho knihy Scrum and XP from the Trenches nebo Kanban and Scrum – making the most of both je i tohle velice pěkně vytvořené video kde se dozvíte vše co jste kdy potřebovali vědět o produkt managementu a roli Product Ownera.

Originál spolu s přepisem textu nejdete zde.

Jak si vyzkoušet Scrum v korporaci která není agilní

Zavádět agilní metody ve velké korporaci je těžší. Přinejmenším musíte pro agilní přístup nadchnout větší množství lidí, což dá více práce. V podstatě máte dvě možnosti. Buď svoláte velký meeting a na něm oznámíte, že od teď je vaše firma agilní a vše tlačíte silou, nebo budete agilní metody stavět od jednotlivých týmů a necháte lidi, aby si sami vybrali, jakou metodikou projekty chtějí řídit. Ze zkušenosti se dá říct, že fungují oba přístupy, což ale neříká, že oba budou fungovat pro každou firmu. Nakonec stejně časem zvolíte jistý mix obou krajních variant. Příkaz a rychlou změnu celé organizace na agilní si asi můžete dovolit, jen když jste si sami jisti výrazným přínosem takové změny a také když víte jak. Většina firmem si ale přechod na agilní organizaci moc představit neumí, takže začíná spíše opatrně.

Asi ideální je zlatý střed. Vybrat produkt, který bychom zkusili řídit agilně, najít vhodného Product Ownera a Scrum Mastera, vyčlenit ze standardní organizace vývojáře, analytiky a testery které plně alokujeme do pilotního Scrum týmu. Vyplatí se vysvětlit jim v 1-2 denním workshopu jak fungují agilní metody, na čem stojí, že je to spíše filosofie a změna myšlení než striktní proces. Aby to nebyla jen teorie, ale věděli i proč jednotlivé praktiky děláme. Když se tým již od počátku zapojí do vytváření Scrum procesu, přijde si sám na to jak proces adaptovat na své podmínky.

Když je i tohle pro vás nepředstavitelné, dosáhli jste správné úrovně klasického korporátu. Je zajímavé, že i drobná agilní změna zanesená do vašeho zaběhnutého systému může přinést ohromné výsledky. Většině týmů schází napojení na business, a protože pro ně není ze začátku snadné v korporaci udělat stabilní Scrum tým se vším všudy, začne standupy. Na začátek tam chodí jen členové IT týmu. I to je přínosné. Když se tým zaběhne, začne jim víc a víc vadit, že nemají přístup k nikomu za business a že zástupci businessu se standupů neúčastní. Tak je pozvou a oni po větším či menším protestování že na to nemají čas, začnou chodit. Obvykle je ale standup rozvleklý a technicky orientovaný, takže to naše zástupce businessu moc nebaví a brblají, že je to pro ně ztráta času. Z tohoto stavu obvykle vedou dvě změny. Vizualizovat lépe stav práce na přehledné tabuli a připomenout že standup je hlavně o commitmentu, tedy o tom co se dokončilo. A abychom mohli mít commitment kterému business rozumí, je dobře dělit práci na nějaké funkční celky které za nějaké fixní období – tedy Sprint dokončíme. Co se udělá, by se měl domluvit tým s businessem a ne si o tom rozhodovat sám jako doposud.

Je zajímavé, že i takováhle agilní ochutnávka stačí k tomu, aby tým začal fungovat výrazně lépe a vzbudilo to v jeho členech chuť zkusit další věci. Sami se ptají jak že se to ve Scrumu plánuje, jak se ohodnocuje, co je to UserStory, začnou dělat retrospektivu, hledat rovnováhu mezi tradičními projektovými funkcemi a nově definovaným rolemi a zkoušejí si, jak by Scrum v jejich prostředí mohl vypadat. Po nějakém čase je v organizaci dostatečně positivní atmosféra pro postavení plného pilotního Scrum týmu. A to je následně začátek přerodu v agilní organizaci.

Je Scrum jen pro male firmy?

Jak se poslední dobou pohybuji ve větších firmách, setkávám se často s názorem, že Scrum je jen pro malé firmy. Tak se pojďme podívat, co se tím v reálu myslí. V korporátech se často objevuje pojem “ideální Scrum“, čímž je míněno prostředí kde je jeden tým, jeden Scrum Master, jeden Product Owner a žádné závislosti. Všichni plně alokovaní, pracují na něčem, co ideálně vytváříme od nuly a co s ničím dalším nesouvisí. Takové jednoduché. A druhým dechem dodávají, že to my v naší organizaci nemáme, my máme ty velké integrační projekty a na nás se agilní metody nehodí. No ostatně každý důvod se hodí, když se chceme bránit změně. Začínala jsem se učit Scrum ve velké korporaci, která měla několik divizí, IT v řádu jednotek tisíců, outsourcing/offshoring a distribuované týmy. A viděla, co se stalo po transformaci na agile a Scrum. Výrazný nárůst efektivity, kvality, zastupitelnosti. A to vše ve velice komplexním prostředí mnoha souvisejících produktů a specifických technologií napojených na vlastní HW. Nebyly to žádné malé internetové projektíky. Proto tomuto argumentu českých firem moc nerozumím.

Ale pojďme se podívat, proč by v prostředí velké korporace mohl být Scrum a agilní metody prospěšné. Takovéhle velké firmy často dokonvergují k zajímavé organizační struktuře. Mají oddělené IT a business. Moc spolu nemluví, moc se nemají rádi. Business dává velice volně definované požadavky – slovy IT neví, co chce – a to IT má na jejich řešení málo kapacit a nestíhá. Všechno je pozdě. A ještě často dodá něco jiného. Takové firmy se snaží tuto nefunkčnost různě házet jeden na druhého. Ti co se na to dokáží dívat s nadhledem, často říkají “Máme velký problém v IT, který ale neleží v IT.“

Jak je business hodně daleko a nemá obvykle příliš motivaci se do projektů zapojovat, tak se týmy obklopí armádou business analytiků, kteří se snaží požadavky businessu dodefinovat a interpretovat IT světu tak, aby pro ně byly srozumitelné. A protože oni za úspěšnost projektu nenesou žádnou zodpovědnost, tak požadavky nijak neořezávají, ba právě naopak. Oni jen plní přání businessu. A rozmýšlí, jak by se taková věc mohla chovat. A tak IT roste a roste a překvapivě pořád nestíhá tu spoustu požadavků businessu zpracovávat. A kdyby mohlo, sedí ve všech budovách a kancelářích po celém městě.

Agilní metody a Scrum proces se snaží organizovat týmy po produktech, ne po technologiích. Základní výhodou potom je, že to co se dělá, není rozhodováno IT nebo analytiky, ale businessem který u každé funkcionality zvažuje, jestli se jim vyplatí do ní investovat energii týmu/peníze. U každé funkcionality se zamyslí nad tím jaký má očekávaný přínos a jakou “pokutu“ bychom ev. platili za její absenci a jestli nám to celé stojí za to. Na to se hodí koncept User Stories (určitě si vzpomenete na zkratku INVEST která je v tomto kontextu docela výstižná). Tohle je tedy kromě lepší komunikace mezi IT a businessem, vyšší motivací a vyšší zastupitelností asi hlavním důvodem pro vyzkoušení agilního přístupu. Říká se, že firmy, které takto řídí svojí funkcionalitu, mohou ušetřit až 80% effortu. Určitě to neplatí plošně, ale podívejte se kolem sebe. Kolik funkcionality se opravdu použije a vyplatí? Kolik toho všeho na čem pracujete, by šlo zjednodušit, kdybychom rozuměli tomu, proč to vůbec děláme. A co by šlo v konečném důsledku úplně nahradit…

Řekněme tedy, že jste mi uvěřili, že by to mohlo mít smysl. Co dál? Jak zformovat stabilní tým v prostředí stovky integrovaných systémů, kde se IT skládá z mnoha isolovaných úzkých specialistů a systémy tvoří chobotnici vzájemně provázaných funkcionalit s množstvím legacy kódu, kterému již nikdo nerozumí? Kupodivu to jde snáze než byste si mysleli. V reálu obvykle dojdete k tomu, že tím, že se začnete na systémy dívat z pohledu businessu, uděláte v podstatě vertikální strukturu proti současné horizontální. Je to jiný pohled. Některé produkty spojíte, jiné rozdělíte, ale ve finále se vždy přijde na to, že systém jde relativně snadno rozřezat na funkční logické produkty, kde je možné stanovit Product Ownera, který má zodpovědnost za návratnost a úspěšnost produktu. Není na to sám, pomáhají mu ostatní kolegové z businessu, business analytici a IT architekti jako doposud, ale je tu někdo, kdo je stabilně zodpovědný za produktovou linii. Dělá jen to co má smysl. Co se vyplatí v dlouhodobém horizontu. To je první část úkolu. Druhá část sestává z definování stabilních Scrum týmů. I to není tak složité, jak by se mohlo zdát. Tým musím obsahovat znalosti klíčových technologií, systémů a architektury. Ale když to zkusíte, zjistíte, že vaše současná chobotnice složená z nenahraditelných a nezastupitelných částeček jde obvykle rozdělit na týmy o cca 7-10 lidech, které jsou schopny většinu práce na nově definovaném produktu udělat sami. Co zbyde, si buď objednají zvenku, nebo se naučí. Větší produkty budou implementovat skupiny 1-4 stabilních týmů, menší projekty se dají sdružit pod jednoho Product Ownera, který má jeden takový tým. Zní to jako utopie, ale zkuste to. Zatím jsem nepotkala firmu, ve které by to nešlo.

Co je na tom nejtěžší? Uvěřit, že i v takto složité a komplexní firmě je to možné. Uvěřit, že by nám taková změna mohla výrazně pomoct. Začít budovat kulturu zodpovědnosti, posílit důvěru, a podpořit transparentní komunikaci v rámci celého systému. Zní to jako fráze, ale funguje to. Je to těžká a zdlouhavé práce. Příjemné je, že jakmile začnete, vaše snaha velice rychle přinese své ovoce a lidem se po prvotní vlně odporu nový proces zalíbí. V ten moment začne být vaše snaha o změnu nakažlivá a vy máte o kousek práce míň.

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.

Agile Riga Day

Rok se s rokem sešel, a tak jsem se zase objevila na Agile Riga Day, příjemné jednodenní konferenci v Lotyšsku. Letos se organizátorům podařilo zdvojnásobit počet účastníků, a rozrostli se na tři tracky. K tomu jsem ještě měla jednodenní workshop, “Starting Scrum“, takový den plný her, simulací a diskuzí. Bylo zajímavé, že slečny převládaly, ostatně i na konferenci den poté jich bylo výrazně více, než bývá v Evropě zvykem. Ale přeci jen méně než na Agile India. Překvapilo mě i to, jak rádi si analytici, kterých jsem na workshopy několik měla, hráli. U nás mám s analytiky spíše opačnou zkušenost.

Riga a vlastně i Lotyšsko má jedno další specifikum. Je hodně navázané na Skandinávii, takže mám pocit, že jsem byla jedním z mála lidí co nebyli z pobaltsko-skandinávské oblasti. Převládali Švédové, Norové, Estonci. O čem se hovořilo? O tom jak psát dobrý kód, jak dělat refactoring, jak naložit se starým legacy kódem, jestli dělat test driven development, nebo pair programming… výborný workshop na toto téma vedl Johannes Brodwall – Extreme Startup. Moc se mi to líbilo. Už dlouho jsem neviděla na konferenci pair programming v praxi. Bylo zajímavé to sledovat.

Hodně se diskutovaly odhady. Vlastně, začali jsme s tím tématem už den před konferencí v místním baru. K pochopení základního problému s odhady je nutné si uvědomit rozpor mez i tím, co odhady jsou – tedy nepřesná predikce budoucnosti – nijak exaktně přesná být z principu věci ani nemůže, od toho je to odhad. A jistá představa managerů některých firem, že odhad musí být naprosto přesný. A když k tomu dodáme nepříjemný pocit členů některých týmů, že jsou tlačeni do něčeho, co není možné dodat – tedy do stoprocentně přesného odhadu, máme tu problém, který se dá dlouho do noci vášnivě diskutovat. Obzvláště když jeden z diskutujících má ráno na dané téma keynote kde v podstatě říká, že odhady v bodech jsou stejně tak špatné, a nepřesné, že zrovna tak můžeme každý Sprint jen počítat dokončené a nedokončené User Story a odhady nedělat vůbec. Příště o tom třeba napíšu víc.

Dalším tématem, které mě zaujalo, byla myšlenka, že na to, abyste změnili svět, třeba na agilní, je třeba si uvědomit že “nemusíte systém řídit, stačí s ním umět tančit“. Možná že to je jedna z věcí, které musí umět každý Scrum Master, a asi nejen on. Nestačí vědět, jak okolní svět funguje, musíte vyvinout něco, co se bude chovat jako virus. A takový virus potom do okolního, neagilního, světa pustit.

Abych to shrnula, myslím, že všechny praktické sessions pro programátory a testery se osvědčili, a že mám zase pár dalších kontaktů a nápadů na konferenci do Prahy – AgilePrague, která bude 3-4. září, 2012.

Konference Agile India 2012

Kolik z vás navštívilo konferenci zaměřenou na agilní metody v zahraničí, a kolik z vás v Indii? Cestuji ráda, takže se to zdálo být jako dobrý nápad. Navíc, chystala jsem se do blízké oblasti na dovolenou, tak proč ne 🙂

Jestli byste čekali, že Bangalore – Mekka IT outsourcingu – bude podobné moderním asijským městům jako Singapore, Kuala nebo Bangkok, tak to ani nápad. Žádná wifi, přelidněné město, všude smetiště a špína. Prostě Indie. Říkala jsem si tedy, že na konferenci uvidím ty IT odborníky, kterých má být Bangalore plné, a že třeba pochopím, proč si velké firmy vybrali pro outsourcing zrovna Indii. Myslím však, že to ani firmy samy nechápou. Jistě, je tu nízká cena. Ale ta je draze vykoupená nízkou kvalitou služeb a ohromným overheadem spojeným s řízením takto distribuovaného projektu.

Takže o čem se přednášelo? Základy, které i v zemích kde se s agilními metodami začíná už dávno znají. Tedy nic, co by stálo za zmínku. Témata, která se řešila, už byla zajímavější. Třeba že Indie je země s nejvyšším indexem “vzdálenosti od zákazníka” – tedy laicky řečeno, na zákazníka kašlou. A taky distribuované týmy a kulturní rozdíly. Zajímavé bylo, že Indové jsou přesvědčeni, že zákazník, když s nimi chce spolupracovat, se jim musí plně přizpůsobit. Třeba není vhodné od nich očekávat, že vám řeknou, jak se věci mají. Budou kývat hlavami, a to, že projekt má problém, se nedozvíte. Když na to jeden ze speakerů narazil, dostal udivenou odpověď z publika, že to je přeci v pořádku, oni si to mezi sebou poví, ale někomu cizímu, to přeci neřeknou. Další z legračních situací popisoval jiný speaker. Proškolili indickou firmu na Scrum, vše se zdálo být v pohodě, ale jen do té chvíle, než představili nové role. A kdy nový Scrum Master říká že se mu Scrum líbí, že mu rozumí, ale jestli si může dál říkat project manager, že by tím že je teď jen Scrum Master utrpěl jeho status a jak by pak před kolegy a rodinou doma vypadal…

Jak tedy chcete v tomto kastovním systému zavádět agilní metody založené na týmové spolupráci, zapojení zákazníka a transparentní komunikaci? Jak chcete dosáhnout self-organized týmu? Těžko. Někdo to na konferenci pěkně shrnul na twitteru: “Outsorcing v Indii je levná možnost jak nechat zkrachovat svůj produkt”. A asi s ním musím souhlasit. Ostatně většina firem už na to přišla také a tak Indii svěřuje v podstatě dva typy projektů. Výběhový SW, který sice musí udržovat, ale nejradši by se ho zbavili, a testování. Ostatně spousta firem netestuje vůbec, tak proč to nedat levně do Indie. I to má však jeden háček. Tím prvním můžete současné klienty odradit a přijít tak o více peněz, než by se z ceny outsourcingu původně zdálo. A co se kvality týče, jak chcete nechat testovat produkt lidem, kteří žijí v souvislém smetišti. Tester musí být precizní, vidět i drobné nesrovnalosti… A to lidé v Indii obvykle nevidí. Prostředí deformuje. Ostatně i mě po třech týdnech v Indii přišlo, že je tam uklizeno víc, než když jsme přijela… Na všechno si člověk zvykne.

Asi nejlepší byla přednáška o distribuovaných týmech kde Alexey Krivitsky pěkně popisoval jak se s takovým prostředím vypořádat. Doufám, že se nám podaří ho nalákat na konferenci do Prahy – AgilePrague, která bude 3-4. září, 2012.

Motivace

Jak efektivně motivovat zaměstnance? Je to jedna z nejčastějších otázek které dostávám hned po tom jak implementovat Scrum. Dobrý Scrum Master by měl umět tým motivovat. Být dobrým koučem. Takže jak na to? Určitě nepotřebujete žádný budget. To že peníze nejsou motivačním faktorem ale demotivačním – tedy ať přidáváte jakkoli, radost z vyšší mzdy či prémie vydrží tak týden. Pak zajdete na večeři, jedete na dovolenou a zas je to všechno jako dřív. Čím více dostanete, tím dříve si přijdete pro další. Ale dostáváte-li méně, než byste vzhledem k tomu co děláte měli, nebo než nutně potřebujete, za poměrně krátkou chvíli jste silně demotivováni. Takže řekněme, že plat je fér. Co ty nejlepší lidi vlastně v týmu drží a neodejdou ani za lepší plat jinam? Obava ze změny? Možná. Ale to nestačí. Dobrý kolektiv, smysluplná práce, pocit že to co děláte je potřeba, a že to má význam. A že to děláte dobře.

Tohle všechno samozřejmě není primární starostí Scrum Mastera. Má kolem sebe pár pomocníků.
Začněme tím co je starostí Product Ownera. Dodávat vaší práci smysl. Product Owner je vlastníkem produktu, potažmo product backlogu a ten musí tým nadchnout, aby ve svém počínání viděl smysl. Customer demo vám v tom jistě pomůže. Pochvala od zákazníka nikdy není k zahození. Pocit, že to co píšete někoho opravdu zajímá. A že to potřebuje. Takže by se dalo říct že Scrum proces vám s motivací také výrazně pomůže. Jestli tahle složka motivace nefunguje, jako Scrum Master to budete nejdříve muset spravit. Jinak práce bude těžko někoho bavit a těžko z kohokoli v týmu dostanete nějaké větší nasazení. Naopak uslyšíte samé výmluvy na okolí.

Takže produktu rozumíme, dává nám smysl, práce tým baví. Co zbývá? Scrum Master pomáhá odstraňovat překážky, tu šílenou práci co vás dřív obtěžovala… Občas pomůže moderovat diskusi, řeší problémy. To ale není vše. Měl by i lidi rozvíjet…

A tady začíná problém. Ve Scrumu by se dalo často říct, že tým je tak dobrý jak dobrého má Scrum Mastera. Scrum Master musí být v jistém smyslu i dobrý manager. Takový, co jednotlivým lidem v týmu věří, že dokáží být výjimeční a pomáhá jim stanovovat si takové cíle, aby byly náročné ale splnitelné. Aby tým pracoval nejlépe, jak umí. Špatný Scrum Master si jen stěžuje, že jednotliví členové nemají potřebné skilly, a že by se to museli učit. A na to že není čas. Dobrý Scrum Master ví, že tým to dokáže. Z hloubi duše jim věří a tým to někde uvnitř pozná. Aniž by taková informace byla kdy vyřčena nahlas. Jen tým pracující pod takovým Scrum Masterem může být ve skutečnosti úspěšný.

Na závěr doporučím jeden článek. Není sice o Scrumu, ale myslím, že dobrý Scrum Master musí vytvářet takový “pygmalion”.