Scrum Gathering India

Cestou z Vietnamu jsem se ještě zastavila v Indii. Musím přiznat, že Vietnam byl příjemnější. Výrazně klidnější a taky tam bylo o dost hezčí počasí 🙂 Ale přežila jsem i cestu vlakem, takže tak zlé to nebylo. Až na ten nekonečný déšť.
Konference se zdá být o dost příjemnější než Agile India před asi rokem a půl. Také účastníci mají více představu o tom, co to je Agile a Scrum, polovina z nich jsou dokonce Scrum Masteři. I program je kvalitnější. Asi je to jako vždy o organizátorech. Na rozdíl od Bengalore mají i dobré kafe, vodu v lahvích, jen internet nějak zapomněli. No co se dá dělat. Asi bez čtení twitteru vydržím. Zrovna by mě ale zajímalo, na co že si Jurgen cestou z Mumbaje stežoval 🙂 ale to se asi dočtu i večer.

Co jsem se dozvěděla? Vlastně mi to připomnělo věci, co už jsem slyšela dříve, jen ještě nebyl čas o nich psát. Když bych to shrnula, zdá se, že jedním z trendů je dívat se na firmy jako komunity, omezit pravidla, zvýšit transparentnost. A o zbytek už se postará “volný trh”. Vždycky jsem říkala, že firma je organismus. Že sám žije a mění se bez ohledu na pravidla a přání lidí. Každé pravidlo jde obejít. Takže je lepší jich mít co nejméně a nechat organismus – trh – tedy firmu a lidi v ní sami rozhodnout, co je pro ně nejlepší.
Jedním z příkladů může být jiný přístup k ohodnocování a bonusům. Osvědčil se převážně ve Skandinávii, a to překvapivě i ve velkých korporacích. Udělali ohodnocování naprosto transparentní. Každý ve firmě dostane přesně stejný bonus a platí jediné pravidlo. Nesmí si ho nechat. Musí ho rozdat komukoli ve firmě. Polovinu klidně může dát kolegovi, co mu pomohl, zbytek rovnoměrně ostatním. Někdo ohodnotí asistentku, někdo své kolegy v týmu. Máte-li málo, stačí vysvětlit svým kolegům, čím jste pro ně přínosem. Je to vlastně aplikovaný princip volného trhu. Samo se to reguluje.
Podobné je to s budgety. Zmíněná teorie se jmenuje Beyond Budgeting. Vychází z toho, že svět se stejně mění tak rychle, že nemá cenu plánovat, které oddělení má kolik na rok dopředu. Stačí jen udělat vše transparentní. Letíte businessem? Proč ne, ale celá firma to uvidí. Chcete lepší laptop, než mají vaši kolegové? Kupte si ho, ale budete si to muset obhájit před ostatními. Studie firem, které to zavedly ukazují, že se výrazně ušetřilo.

Obě teorie je velmi těžké implementovat. Obzvláště v některých prostředích a kulturách. Stejně jako při delegování drobných development praktik na tým musíte postupovat krůček po krůčku. Tým k tomu nejdříve musí dozrát. Jestli se dnes nedohodnou ani kdo a jak bude software testovat, asi pro delegování ohodnocení na členy týmu nebude ještě ten pravý čas. A trvat to může dlouho. I mnoho let. Takové věci se nemění snadno a nejdou uspěchat. Je ale dobré o nich vědět a směřovat k větší a větší delegaci od manažerů k týmům.
Souvisí s tím ještě jedna praktika. Když už nechcete začít zrovna hned s penězi, rozhoďte o firmě “kudu appreciation cards” tedy takové pohledy, které může kdokoli komukoli napsat a dát, aby mu za něco poděkoval. Kolega kolegovi, asistentce, recepční. Poděkování má často silnější efekt než jakékoli peníze. Zkuste to a uvidíte.
A ještě jedna myšlenka mě na Scrum Gathering India zaujala. Bob Hartman mluvil o tom, že to, co dělá Scrum a Agile úspěšnými jsou lidi. Ti jsou nejdůležitější. Když jsou spokojení, funguje to. Když ne, žádný proces nepomůže. Agile není ani o procesech a v konečném důsledku ani o praktikách. V tom jsme se ostatně oba v našich přednáškách shodli. Přidával však ještě jednu zajímavou hodnotu agilnímu manifestu – úspěšné týmy upřednostňují “my” před ” já”. We value ´we over me’. Když se tím budete řídit, zmizí pomyslné zdi mezi jednotlivými specializacemi. A začnete fungovat jako tým. Tým, který má jeden cíl. Ne mnoho individuálních protichůdných cílů, které se vzájemně popírají. A to je to, čeho se celým Scrumem a Agilem snažíme dosáhnout.

A na závěr, ještě jeden příměr. Schalk Cronje přirovnával obsesi metrikami k řidiči, který se cestou vůbec nedívá na cestu, ale pohled má upřený na tachometr. Věřím, že takovými řidiči nejste, ani byste se s nimi na silnicích nechtěli potkávat. Proč ale ve firmách až příliš často zapomínáme na selský rozum a pohled máme upřený pouze na různé tachometry…
Obecně to byla velmi příjemná konference. Účastníci se opravdu chtěli něco dozvědět, ptali se. Využívali každou chvilku k dotazu. Takže se do Indie zase ráda vrátím, bude-li příležitost.

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 agile očekává od Managera?

Jak tak chodím po firmách, dostávám se do spousty zajímavých prostředí. Výborných týmů, kde lidé mají energii a svítí jim očíčka. Jsou nadšení. Něco chtějí, zajímají se. Pochopí, o čem je Agile a Scrum, a začnou ho implementovat a adaptovat na své podmínky. A většinou jim takový proces velmi rychle začne fungovat a při nasazení agilních metod nesklouznou k tupému vykonávání praktik a ceremonií. Rozumí proč, pochopí agilní filosofii a kulturu a jsou ochotni pro takovou změnu i něco udělat, vydat pro její změnu energii. Pomáhat nasazovat Agile a Scrum v takových firmách je moc fajn.

Na druhé straně spektra jsou firmy, kde lidé ani nereagují na světlo. Někde se bojí, panuje tam atmosféra strachu, striktních procesů, tvrdých metrik a postihů. Finančních pseudomotivací navázaných na výsledky, které bez ohledu na jejich výši selhávají. Veškerá iniciativa se trestá. Dělejte přesně to, co jste dostali v zadání a nad ničím nepřemýšlejte. Hlavně buďte efektivní. V jiných firmách je to jen rezignace. A nedostatek motivace. Všem je všechno jedno. Oni jsou jen zaměstnanci. Trafikanti. V obou případech obvykle schází iniciativa a také, a to hlavně, důvěra. Lidé jdou sami na sebe, neřeknou si do očí pravdu. Často ji nepřiznají ani sami sobě. Zavádět agilní metody v takových firmách ani nejde. Tedy, nejdříve musíme ty lidi probudit a nechat je vyříkat si staré křivdy. Je to více o Maslowovi, než o Agilu. Agilní metody jsou v takových prostředích až na druhém místě. Nejprve musíme postavit funkční tým, dolít jim energii, dodat sebedůvěry. Agile ani Scrum není žádná zázračná pilulka. Když spravíme důvěru a otevřenou komunikaci mezi lidmi, můžeme začít pomalu s agilními přístupy a procesy.

Přemýšlela jsem o tom, čím to je. A mým závěrem je, že je to o managerech. Ti první jsou dobrými leadery. Jejich cílem je mít kolem sebe úspěšné lidi a svůj vlastní úspěch neměří podle splněných KPI, ale podle spokojenosti lidí, legrace, výsledku, ale i atmosféry. Ti druzí se schovávají za procesy a metriky, bojí se, že by je šikovnější kolega mohl časem přeskočit. A nebo prostě jen omylem byli ve správný čas na správném místě a stali se managery. Často jim nikdy nikdo neporadil jak na to. Tým je odrazem managera. Je nadšený, aktivní a úspěšný, když to děláte dobře. Je v depresi, stresu a nestíhá dodávat, když to děláte hůř. V obou případech vám Agile pomůže. V prvním vám jen ukáže jak na to, v druhém vám pomůže dodat sebejistotu, že takhle je to správně. Stačí jen postupovat podle příručky, jako ti všichni přede mnou. Dodá vám sílu lidem věřit, pomáhat, a že oni to už s pomocí agilních procesů zvládnou.

Když ve špatném týmu hledáte Scrum Mastera, často se jím stane člověk s tzv. největšími zásluhami. Ale ten se velice často na Scrum Mastera nehodí. Byl by dobrým analytikem, architektem, expertem. Ale jeho hlavním cílem není dělat lidi kolem sebe úspěšnějšími. Nebo někdo neslaný, nemastný, kdo si vezme za cíl být neviditelný. Scrum Master přeci nemá být direktivní, že. Nojo, ale musí něco chtít, motivovat, hlídat Scrum proces. I Scrum Master je odrazem managera.
Cílem managera není na denní bázi kontrolovat jednotlivce a určovat, jak přesně budou pracovat. Cílem je vytvořit takové prostředí a podmínky, aby se vašim Scrum Masterům a týmům dobře pracovalo. Většinu času byste tedy měli mít čas na strategická rozhodnutí, směřování vašeho departmentu, apod. To ale neznamená, že nevíte, co jednotlivé týmy dělají. Ty, co perfektně fungují, vás nemusí vidět rok. Ty, co ovšem optimálně nefungují, si musí zvyknout na vaši přítomnost a akceptovat ji. Znovu to zopakuji, není cílem managera zasahovat do každodenní práce jednotlivců. Manager je pozorovatel. Ale jestli neví, co se mu v departmentu děje, tak proč tam potom je. On je ten, kdo je za fungování ve finále zodpovědný. A jestli pro úspěch týmu musí chvíli učit Scrum Mastera jak má Scrum Masterovat, nebo ho vyměnit, je to přesně to, co od něj potřebujeme. Manager má fungování zajistit.

Standardně radím delegovat. O několik stupňů víc než se vám chce, než jste zvyklí. Ale když měníte kulturu, možná dočasně budete muset pomoct tuto novou kulturu utvářet. Pomoct jí vzniknout. Být přítomní. Sami se do té změny zapojit. Když to neuděláte, obvykle se nic nezmění. Lidi necítí vaši podporu, a často ani nevěří tomu, že změnu opravdu chcete. Buďte jim příkladem, prožijte změnu s nimi, Jen tak bude opravdu úspěšná a z agilní transformace dosáhnete maximum.

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

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

Procesy a metriky deformují lidi

Čím více chodím po firmách, tím více docházím k tomu, že existuje jasná rovnice. Čím striktněji nadefinované máte procesy, tím méně je ve firmě inovace, otevřenosti, důvěry, motivace, iniciativy, spolupráce. Lidé sedí a čekají, až dostanou úkoly. Bojí se ozvat, starají se jen o to, jak naplní metriky. Produktivita klesá, a čím více klesá produktivita, tím více metrik vzniká. Co neměřím, to neřídím.

Agilní metody to dělají jinak. Místo striktního procesu jen vymezují hřiště. Definují týmům i jednotlivcům pouze mantinely, které by se neměly překračovat. Už jen agilní manifest. Neříká takhle přesně vypadá/nevypadá dokumentace, ale “upřednostňujeme funkční produkt před vyčerpávající dokumentací“. Tedy jediné co říkáme je, že “je to o produktu, ne o dokumentaci“. A nepřímo i to, že dokumentace je důležitá, ale komunikace je důležitější. Tedy, určitě dokumentaci dělejte, ale asi není třeba ji mít sepsanou do posledního detailu, sepište jen to, co opravdu bude někdo potřebovat. Zdánlivě tedy neradí nic. Je to common sense. Selský rozum. Na ten jsme ale při našem pracovním vytížení často zapomněli. Agilní procesy nás vrací tam, kde jsme kdysi byli. Tam, kde věci fungovaly i bez detailních metrik a přesně definovaných procesů.

Jak takové metriky často vypadají? Pár historek pro příklad z poslední doby…

Počet řádek kódu. Ta patří k mým oblíbeným. Musíme přece vědět, který vývojář je lepší než ten jiný. No ne? Jak bychom to jinak zjistili? A jak bychom docílili toho, že vůbec něco dělají. Tedy důvěra: nula. Spolupráce: ani vzniknout nemůže. Protože pak bych kolegovi pomohl k lepší výplatě, což o to, ale sobě tím pádem k horší…

Počet testů, pokrytí testy. Zdánlivě smysluplná. Ale jak jistě testeři potvrdí, zcela nevypovídající. Tedy končí tunou testů. Test máme na všechno, co jde. Obzvláště na ty jednoduché věci. Tam počet přibývá nejsnáze. A protože testování nikdo kromě testerů nerozumí, jediné, co manager honí, je procento pokrytí. A má dobrý pocit, že roste. Jenže ty testy musí někdo udržovat, a to stojí energii. Zbytečně investovanou hned dvakrát. Jednou u vzniku testu, který není až tak klíčový a podruhé opakovaně při libovolné změně systému. Cílem firem, které to pochopily, již dávno není 100% pokrytí testy, ale funkční produkt. Psát jen ty testy, které mají pro nás smysl a potřebujeme je.

Počet reportovaných chyb. Zdánlivě správná metrika. Když ale přitvrdíte, a začnete ohodnocovat testery podle počtu nalezených chyb a vývojáře podle stejného počtu penalizovat, dojdete k tomu, že tyto skupiny mají zcela odlišné cíle. A to, že by spolupracovaly již v průběhu na kvalitním vyřešení User Story je v nedohlednu. Jen ať tam ty chyby udělají. Alespoň je snadno najdeme. A z druhé strany tento přístup generuje nekonečné a často úspěšné diskuse typu: “ne,ne,ne, to není chyba, tu já jako vývojář neakceptuji, to je change request, nebo chyba testu, ale rozhodně ne chyba kódu. Kdepak.“ Frustrující.

Čas na dokončení tasku. Obvyklá věc, že? Jak jinak byste věděli, jestli závazek ve Sprintu stihnete nebo ne? Potřebujete mít přeci jistotu! Ale ono to nikam nevede. Jistota je jen pofidérní. Navíc, takové výpočty stojí spoustu času, který by šel smysluplněji investovat jinak. Stačí přece práci rozdělit na menší kusy a ty přehledně zobrazit na tabuli. A vnímat funkcionalitu jako celek. Ne jako jednotlivé části. Příště o tom napíšu víc.

Sprint Burndown. Obdobně zbytečný jako reportovat čas potřebný na dokončení tasku. Když k němu přidáme tlak na to, aby vypadal “pěkně“, často dojdeme k tomu, že tým reportuje za každý den 8h*počet členů. Tolik času jsme přeci na táskách strávili, ne? Graf má krásný lineární průběh, ale vypovídající schopnost je nulová.

Velocity musí být nějaké konkrétní číslo. Třeba řekněme 22. Jinak tým funguje špatně a málo toho udělá. No tak proč ne, stačí říct a my budeme ještě lepší. Prostě jen začneme ohodnocovat User Stories jinak. Nebo rovnou celý Backlog vynásobíme 100. Jo, to že nesmíme? No tak jo, ale ono se to za nějaký čas objeví na kvalitě. Technický dluh je moc príma. Jeho odstranění je ještě dražší, než to, že si dáte pozor, aby nevznikl .

A pokračovat bychom mohli dalšími složitostmi, jako detailními výkazy o tom, co kdo přesně kterou minutu dělal, nebo kvótou na počet business bodů, které tým musí doručit. A přitom nic z toho není potřeba. Nevěříte? No těžko vás budu přesvědčovat takhle od stolu. Zkuste to. Zeptejte se firem, co to dokázaly.

Obecné doporučení je, že je dobré něco měřit, ale libovolná metrika musí být jen indikátor, ne cíl, pravidlo, modla. Nelíbí se vám velocity? Mysleli jste si, že by tým toho měl doručit více? No tak se podívejte čím to je. Najděte příčinu, ne důsledek. Libovolné tvrdé metrice se tým přizpůsobí a upraví své chování tak, aby metrika vyšla. Některé firmy je proto často mění, aby to týmy nestíhaly. Jiné pochopily, že o problémech je dobré vědět, a jsou rády, že je pomocí soft metrik vidí.

Druhá rada říká, nebabrejte se v detailech. Stojí moc energie a ztratíte se v nich. Všechno je vidět z jednoduchých trendů. Obvyklé věci se totiž dějí obvykle, výjimečné výjimečně. A na velkých číslech, jako je např. velocity za tým a sprint to vychází. I těch neobvyklostí nám za tým a Sprint přijde pokaždé stejně. Jedna User Story byla podhodnocená, jiné dvě nadhodnocené, jeden onemocněl, dalšího bolela hlava, někomu to zas výborně šlo od ruky. Tedy, když přestanete řešit detail, jako je počet hodin na tasku, ale podíváte se jen na velocity, dozvíte se z trendu přesně to, co potřebujete.

Tvrdé metriky a detailní procesy zabíjí tvořivost, inovace, náladu. Končí tak, že produktu nikdo nevěří, z těch úžasných vývojářů, analytiků a testerů, co mnohdy mají několik titulů a jsou nadprůměrně inteligentní, se stávají dělníci u pásu. Zombie bez energie. Udělejte si test. Zeptejte se vašich zaměstnanců, proč pracují. Ti, co jsou tam jen pro peníze, berou práci jen jako nutné zlo. Hlídají si spokojeného šéfa a metriky. Schovávají se za procesy. Vymlouvají se. Jak malé děti. Děláme přece přesně to, co řeknete. Tak nás nechte, a plaťte nám. My máme hypotéku. Uvidíte nás tu maximálně od devíti do pěti, a když tu není šéf, tak jen do čtyř. Přesně podle pracovní doby. Ti druzí, u těch je na prvním místě práce, která má smysl, svítí jim očička, jak tuhle říkal jeden jejich manager. Zajímají se, jsou schopni se zdravě pohádat o řešení, nebojí se říct svůj názor. Mají společný cíl. A tím není mít víc peněz. To je důsledek jejich přístupu, který zákonitě přijde. Kde byste chtěli pracovat vy?

Agile tohle prostředí mění. Mohlo by se sice změnit samo, i bez agilních přístupů, ale často je k tomu nějaký nový label potřeba. Překvapivě, velká část týmů, které dnes coachuji, řeší přesně tento problém. Výhodou je, že že změna přichází rychle. Nabaluje se to jak sněhová koule. Přitahuje to. Ale začátky jsou obvykle o to více bolestivé.

Všechno je o self-organized týmu

Byla jsem si na na přelomu roku odpočinout na Filipínách. Potápění, krásné resorty na pláži. Ale proč o tom píšu. Jak jsem tak sledovala práci třeba Moniky, belgické manažerky prvního dive resortu kde jsme se objevili, nemohla jsem se zbavit dojmu, že tuhle práci bych prostě dělat nemohla. Neustálé upomínání lokálních děvčat co mají dělat, jak to mají dělat, neustálá kontrola. Místní expati říkali, že Filipínci prostě takoví jsou. Řeší jen aktuální okamžik, když se jim zrovna nechce, tak do práce nepřijdou. Kvalita jim nic neříká, vždyť na tom přeci nezáleží. Že namontovali umyvadlo křivě? Vždyť ta voda z kohoutku teče, tak co. Všichni se shodovali na tom, že se musí neustále kontrolovat, hlídat, a že to chce tvrdou ruku. Není to o penězích. Peníze dostanou, utratí, a už další den z nich z nic nezůstane. Ani ta radost, nic. Například když dáte opraváři střechy velkou zálohu, že práci chcete rychle a vám prší do domečku, tak čím větší ta záloha byla, tím déle trvá, než opravář nakonec dorazí. Slibuje, že už zítra, ale takový slib nic neznamená. A tak všichni majitelé resortů aplikují cukr a bič, definují jasné role, pevné procesy. Výsledek takového řízení je v zásadě ok. Nakonec člověk je na dovolené, tak nějaké ty nedostatky bere jako místní kolorit a nijak zásadně to nevadí…

Na poslední týden jsme si vybrali takový malý resort. Vlastnili ho Dánové. Opuštěný ostrov někde v moři. Nádherné místo. Po pár dnech mi začalo vrtat hlavou, co je tady jinak. Že by si Dánové uměli lépe vybrat a našli si motivovanou pracovní sílu? Že by tady bylo jiné etnikum? Pracovitější? Rozdíl byl ohromný. V kuchyni a na lodi samá legrace, úsměvy, a služby v podstatě perfektní. A žádná viditelná kontrola. Takže ono by to nakonec nebylo Filipínci? Poslední den jsem si povídala s jedním z majitelů a ptala se, jak to dělá, že sehnal takové dobré zaměstnance, že mu resort funguje výrazně lépe než jiné, které jsme cestou potkali… A k mému ohromnému překvapení říkal – my jsme z nich udělali tým. Dali jsme jim zodpovědnost a jistou volnost. Neřídíme, kdo má přesně co dělat. Bereme je jako sobě rovné. Chodíme do kuchyně, děláme si legraci, smějeme se. Když mají problém v rodině, pomůžeme jim. Vyjdeme jim vstříc. Třeba například zítra je tu fiesta. Ohromný svátek. A oni se ptali, jestli je pustíme, jestli smí jít. No, když se vrátí ráno včas, aby připravili snídani, tak ať jdou a diskotéku si užijí. Ostatní resorty je nepouštějí, protože by druhý den nikdo nepřišel. My dneska nemusíme osobně jezdit pro hosty do města. Můžeme tam poslat někoho z našich zaměstnanců. A to nám ohromně uvolnilo ruce. Máme čas i pro sebe…

Aha. Nevím proč, ale přišlo mi to povědomé 🙂 Jinými slovy, všechno je to o schopnosti tvořit týmy. Dát lidem zodpovědnost, a možnost se rozhodnout. Self-organized tým (nebo samoorganizující se tým, chcete-li). Výsledek je ohromující. A jak se ukazuje, v každém prostředí. Lidé budou tak dobří, jak dobří jsou ve vaší představivosti. Manager, který si myslí, že jeho zaměstnanci jsou pitomci a nikdy neudělají nic pořádně, s nimi bude zápasit a bude mít problémy. Ten kdo jim věří a bere je za své partnery, bude mít výrazně více úspěchu.

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.