Tag: product owner

Agilní Architektura

Poslední dobou dostávám hodně otázek na to, jak má fungovat architektura v Agilních týmech. Čistý Scrum roli architekta nemá. Mluví o samoorganizujících se zastupitelných týmech. Když to škálujeme dál, tak se mluví o Scrum of Scrums. Ale architekti nikde. To ale neznamená, že nejsou potřeba.

Jak to tedy vypadá v jednoduchém případě jeden Product Owner, jeden produkt, jeden Scrum tým. Tam je architekt součástí týmu. Je to zkušený vývojář, který se dívá dopředu na celý produkt a pomáhá týmu zvolit takové řešení, které vyhovuje celkové vizi produktu. A protože Scrum má pravidlo, že tým pomáhá Product Ownerovi, pak takový architekt spolupracuje s Product Ownerem na tvorbě Backlogu. Pomáhá mu odstraňovat rizika, dodefinovává akceptační kriteria.

Když to škálujeme na větší produkty, kde je více týmů, pak obvykle máme dva typy architektů. Jednoho – ‘velkého‘ – který je na úrovni celého produktu a stanovuje pro týmy takzvanou runway, v rámci které by se měli držet. Takový architekt je součástí týmu Product Ownera a dívá se spolu s ním klidně i několik let dopředu. Zároveň v každém týmu je takový ‘menší‘ architekt, který týmu pomáhá porozumět dané architektonické runway a dělat v rámci ní každodenní drobná rozhodnutí. Všichni tito architekti jsou samozřejmě v častém kontaktu a společně definují architekturu produktu. Jedna z dobrých best practices je, že na takovýchto velkých projektech dělají týmy nejen review mezi sebou, ale věci zrevidované v rámci týmu posílají na takzvané architecture review ‘velkému‘ architektovi. Ten samozřejmě neprochází v detailu všechny změny, ale dává pozor, aby změny byly konzistentní a odpovídaly dané architektonické runway.

No a jestli chcete o Agilní architektuře vědět víc, přihlaste se na workshop “Architecture with Agility“ který vede Kevlin Henney před konferencí Agile Prague 2014, v pátek 12. září. Nebo na konferenci samotnou 15.-16. září, kde jedna z keynote, kterou přednese Peter Eeles, je na téma “Architecture, Agile and DevOps“.

A co o workshopu píše Kevlin?

  • I will be covering the following topics during the day:
  • Defining software architecture as a service to the business
  • The relationship between development process and software architecture
  • The relationship between architecture and development teams and practices
  • The importance of code habitability
  • Empirical processes and architectural decisions as hypotheses
  • The Worse Is Better approach versus the up-front approach to architecture
  • Dealing with uncertainty and change, and using uncertainty and change to define the architecture
  • Architectural properties and requirements
  • Different architectural styles and patterns and their trade-offs
  • Identifying and managing technical debt
  • Refactoring, rewriting and re-engineering
  • Decoupling and dependency management

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.

Výsledky Vánočního Dot Votingu

Jak jsem slíbila, je tu výsledek Vánočního dot votingu. Než se dostanu k výsledkům, zhodnotím službu jako takovou. Z obrázků to vypadá jako dot voting, když ale službu zkusíte, najdete obyčejné radiobuttony. Ani nemáte možnost dát více hlasů jedné možnosti. Tedy když to shrnu, s dot votingem to má společné tak akorát to jméno. Od registrace nevidíte tečky ani v administraci ani při hlasování. Prostě podfuk. Škoda. Mohla to být pěkná služba pro distribuované týmy.

Ale když už jsem to vyhlásila, na otázku: “Kdybyste chtěli dát vaší firmě dárek k Vánocům darek, který stačí jen rozbalit a je naimplementováno. Co z Agilních metod byste jí nadělili?” vyhrály následující tři možnosti:

  • Scrum
  • Product Owner role
  • Agile Management

    • Vlastně to není nijak překvapivé. Úspěšnému nasazení Scrum procesu obvykle ve firmách stojí v cestě právě nepochopení a nízká podpora managementu a neochota Product managementu se do celého procesu zapojit a převzít odpovědnost za Product Backlog a jeho priority. Bez těchto dvou částí Scrum úspěšný nikdy nebude.
    Takže ať se vám v novém roce daří.

    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 🙂

    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.

    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íň.

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

    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.