Tag: tým

Jak vybudovat Agilní organizaci – Organization and Relationship Systems Coaching (ORSC)

Nedávno jsem prošla docela náročným, a to jak časově tak komplexitou, tréninkem Organization and Relationship System Coaching – ORSC.  K čemu je to dobré? Umět posunout firmu na další level. Není to zaměřené na jednotlivce, ale na týmy, oddělení a celé organizace. A není to ani explicitně specializované na Agilní prostředí, nicméně je to v obecné rovině zaměřené přímo na ‘Level 3‘ mé práce, tedy jak posunout firmu, která už Agilní je, na další level. Ale začněme pro jistotu od začátku. Zkusím v rychlosti na jednoduchém modelu vysvětlit, jak vlastně dneska pracuji. A pokud to již znáte, můžete přeskočit rovnou na ‘Level 3: Next level‘.

Level 1: Školení týmu

Obvykle to začíná workshopem. Jako první krok uděláme dvoudenní školení pro jeden pilotní tým nebo samozřejmě i rovnou všechny vaše týmy, když už máte jasno v tom, že Agile je ta cesta, kterou se chcete vydat. Předcházet může půldenní workshop s managementem, kde si ujasníme očekávání od takové změny. Projdeme přehled Agilních přístupů, praktik a metod, kde se na závěr společně domluvíme, jak začneme. Je to o předávání zkušeností s Agilními přístupy, ale hlavně o nastartování změny mindstetu a celkové kultury. Na jak dlouho to je? Stačí dva dny prakticky vedeného workshopu.

Level 2: Transformace

Když už nějaký základ máte a chcete pokračovat dál, je tu fáze zvaná Agilní transformace. Co to znamená? Že jste se rozhodli, že do toho opravdu jdete. Že vaše očekávání od takové změny je dostatečně velké a díky nim dokážete změnu dotáhnout do konce, jinými slovy že vám to stojí za to. A nikdo nesliboval, že to půjde samo, ani že to bude snadné. Každá změna něco stojí, takže i při Agilní transformaci budeme narážet na spoustu nedorozumění, nepochopení, resistence, překážek, ale samozřejmě i úspěchů již na úplném začátku.

Agilní coaching se zaměřuje převážně na Scrum Mastery, Product Ownery a managery. Je to o facilitaci, coachingu, vysvětlování Agilních praktik, a hlavně praktických doporučení. Je to fáze, která má změnu dotáhnout do konce tak, aby vám přešla do krve, aby byla dlouhodobě udržitelná a prostě fungovala. Zkušenosti z Agilních týmů v různých prostředích je tu zcela klíčové. S čistou teorií si tu nevystačíme. Jak dlouho taková fáze trvá? No obvykle 3 měsíce až rok, v závislosti na kontextu a velikosti firmy. Intenzita obvykle jeden den za Sprint.

Recharge

No a následuje třetí level … Ne však vždy rovnou po Agilní transformaci, ale často je mezi těmito dvěma levely takzvaná ‘Recharge‘ perioda, kdy firma pokračuje sama, spokojená s tím jak se transformace povedla. Pozvolna se zlepšuje, zkouší nové věci, posouvá se dál. Po nějaké době ale získá pocit, že by byl třeba nový pohled, že by bylo potřeba to posunout o level dál. A je čas na Level 3 a Organization and Relationship Systems Coaching.

Level 3: Next level

Poslední fáze tzv. Next Level vás posune vždy o kus dál. Obvykle se jedná o firmy, které už Agilní jsou, rozumí konkrétním metodám nejen po povrchu, ale mají i vlastní zkušenost. Ale v podstatě můžeme takhle pomoct jakékoli firmě či týmu bez ohledu na to jestli jsou Agilní či ne. Použité principy a postupy postě fungují obecně, což je fajn. Je to chvíle, kdy vám to jde, ale někde v kostech cítíte, že by to mohlo jít lépe. V takový okamžik přichází na řadu coaching na úrovni systému. Tedy týmu, oddělení, nebo organizaci jako celku. Samozřejmě v Agilním světě jsou tyto metody doplněné znalostmi a zkušenostmi z Agilního světa. Na rozdíl od individuálního coachingu tu klientem nejsou jednotlivci, ale páry a skupiny, tedy systém. Nezaměřujeme se na vyřešení konkrétních problémů jednotlivců, ale na celou entitu a vytvoření, zlepšení či upevnění vztahů mezi jednotlivými lidmi, protože dobře fungující systém si takové problémy už zvládne vyřešit sám. V rámci Organization and Relationship Systems Coachingu se díváme na tým, oddělení, nebo firmu z ptačí perspektivy a v rámci coachingu takovým entitám pomáháme vidět věci jinýma očima. V podstatě coach nastaví celému systému zrcadlo, ve kterém nejsou detaily ani individuální pohledy jednotlivců na věc, ale je vidět jak celý systém funguje. A právě ORSC je frameworkem, který na takové úrovni pomáhá coachům pracovat. Není to snadné, chce to tréning. Ale funguje to skvěle. Věci, se kterými klasickými metodami nejde hnout, se najednou odblokují.

Jak jsem již psala, Organization and Relationship Systems Coaching – ORSC je framework který je zaměřený na páry a skupiny. Spektrum použití je opravdu široké. Pomáhá úspěšně řešit konflikty ať již v osobním životě, nebo pracovním. Je výborný pro zvýšení motivace, posílení aktivity týmů, pomáhá takové týmy tvořit.

A tak třebaže ORSC není přímo zaměřený na Agilní svět, je v tomto prostředí výborně použitelný. Protože o čem jiném je Agile než o schopnosti spolupracovat a vytvořit dobrý tým – ať už se zaměříte na development tým, Scrum tým, celý produktový tým, nebo virtuální týmy které jdou přes celou organizaci a starají se například o lepší Continuous Integration nebo testing. V tomto kontextu je OSRC ideálním souborem nástrojů jak takový Agilní tým postavit a udělat rychle efektivní a funkční.

Tahle fáze je obvykle periodická. Může probíhat s frekvencí 3 dny dva až třikrát do roka, nebo intenzivněji, řekněme den v týdnu po dobu 3-6ti měsíců s následným delším rechargem. ‘Perfection’ totiž není cíl, ale cesta. Tedy řečeno jinými slovy, ideální tým neexistuje, ale pokaždé je tu nějaký prostor jak se zlepšit. Japonci tomu říkají Kaizen, Agile a Scrum to nazývá continuous improvement. Ale v každém případě je tady v každý okamžik prostor pro změnu a zlepšení. A takový prostor v této fázi hledáme a využíváme.

Planning meeeting na 30 minut – část 2

Jak jsme již říkali v minulém článku, celý Planning meeting se komfortně vejde do 30ti minut. Pojďme se tedy podívat, jak vypadá jeho druhá část. Tým má vybrané User Story na tabuli a v rámci této fáze rozpadá jednotlivé funkcionality na konkrétní činnosti, které nebudou podle jejich předpokladu větší, než aby šly dokončit v rámci jednoho dne.

Na rozpadu pracuje celý tým najednou a paralelně plní tabuli lístečky s jednodenními tásky. Když jednotliví členové týmu rozpad dokončí, společně revidují, jestli na něco nezapomněli. Stejně jako v minulém případě, je dobré se podívat kolik tásků na tabuli vzniklo. Obecně platí, že User Story s vyšším ohodnocením se rozpadá na více drobných aktivit než menší User Story.

Ale není to matematika. Jestli jste naplánovali Sprint Backlog, kde počet lístečků odpovídá práci týmu na dva dny, máte buď příliš nízký commitment, nebo jsou jednotlivé tásky výrazně větší než jeden den, a nebo vám některé aktivity zcela chybí. Naopak, naplánovali-li jste tásků stejně jako je dnů*počet členů týmu, máte vysokou pravděpodobnost, že to nestihnete. Vždycky se něco protáhne a na něco jsme vždy zapomněli. Polovina tohoto čísla může být reálná.

Když jako tým souhlasíte s rozpadem, podíváme se ještě jednou na výsledný Sprint Backlog a eventuálně ho upravíme (přidáme / ubereme nějakou User Story) a o výsledném commitmentu informujeme Product Ownera.

Nutnou podmínkou takového rychlého Planningu je dobrá příprava. Tým nesmí vidět User Story poprvé na Planningu – už se s nimi dobře seznámil na Backlog Groomingu, kde je i ohodnotil. Zanedbat se nesmí ani příprava na rozpad User Stories na jednotlivé aktivity. Tým zná prioroty pro další Sprint několik dní dopředu a může si tak zavčas popovídat o řešení a připravit se na jejich rozpad.

Zkuste a uvidíte, že to není zas tak těžké, a že to funguje. A navíc, jako bonus ušetříte spoustu času a získáte kvalitnější Sprint commitment.

Planning meeeting na 30 minut – část 1

Často s týmy diskutuji na téma, že Scrum jsou jen samé meetingy. A tak začínám tím, že s nimi projdu, jak mají být jednotlivé meetingy dlouhé. Většinou se zasekneme na Planningu, který byste měli v pohodě zvládnout za 30 minut. Jak takový planning vypadá? Tým si nejdříve v cca 15 minutách vybere, které User Story z priorit Product Ownera by mohl dokončit. Ideální je, když opravdu fyzicky vybírá, které z kartiček na stole dá na svoji Scrum tabuli. Jednotlivé User Story a jejich business hodnotu si může tým ještě upřesnit s Product Ownerem, ale výběr je na nich.

Je tedy nasnadě, že jich Product Owner musí přinést dostatek, aby bylo z čeho vybírat. Tým tím přebírá větší zodpovědnost, a také musí produktu po všech stránkách více rozumět, než když jen bere User Stories jednu po druhé podle přesných priorit Product Ownera. Zároveň je to také často efektivnější, protože tým může vybrané User Story přizpůsobit svým zkušenostem a znalostem a optimalizovat tak dokončenou funkcionalitu v rámci priorit Product Ownera.

Fyzická reprezentace ve formě kartiček jako obvykle pomůže. Usnadňuje to týmu převzít kolektivní ownership a zodpovědnost za výběr. Jak jednotliví členové týmu navrhují, které User Stories by tým mohl stihnout, někde se to ve výběru zastaví. A členové týmu si již nejsou jisti, jestli by další věc stihli nebo ne.

Tým si může ještě udělat rychlá cross-check obvyklé velocity, když vyšlo řádově jiné číslo, tak je to dobrý indikátor k zamyšlení se, co nás vede k tomu, že toho tentokrát stihneme dvojnásobek, nebo naopak polovinu, a případné revizi návrhu Sprint Backlogu.

Tady první část Planningu končí, Product Owner i Scrum Master nechávají tým pokračovat druhou 15ti minutovou částí a odchází.

Jak na performance metriky?

Jedním z častých problémů, na které firmy v průběhu Agilní transformace narážejí, je jak řešit performance metriky. Moje doporučení je zaměřit se více na soft ukazatele než tvrdé hard metriky. Mně se osvědčilo používat relativní coachingovou stupnici 1-10. Kde 1 je nic moc, 10 je super. Ideální je, když necháte lidi, ať se sami ohodnotí. Otázka, na kterou je dobré se zaměřit, je třeba co by se muselo stát, aby to bylo místo šesti sedm, nebo osm.

A protože každá metrika se dá ohnout tak, že přestane fungovat, ideální je metriky měnit. A když chcete jít ještě dál, zkuste umožnit zaměstnancům, ať si svoje metriky zvolí sami. Podpoříte tak jejich zapojení a zodpovědnost. Je to jistě zásadní změna, ale ve finále, proč to nezkusit. Nechte týmy, ať se domluví i na týmových metrikách. Jedním z pravidel je, že metriky mají sloužit ke zlepšení týmu, jednotlivců nebo procesů, mají něco měnit. Jinak nemají smysl. A právě proto musíte měřit pokaždé něco trochu jiného, často i protichůdné ukazatele. Jak na základě měření upravujete vaše procesy a praktiky, tak se potřeba jednotlivých ukazatelů také mění.

Na závěr zbývá dodat, že takové metriky a ukazatele je třeba často vyhodnocovat. Jinak ztrácejí smysl a jediným výsledkem může být demotivace zaměstnanců. Nechte systém transparentní, ale nemikromanagujte jednotlivá čísla. O zlepšení na základě volněji definovaných ukazatelů se pak postarají jednotlivci a týmy. Výsledek daleko předčí jakékoli shora definované KPIs. Těmi už nebudete muset ztrácet čas. Ale než o tom přesvědčíte vaše HR a management, je dobré si takový systém vyzkoušet a naměřit jeho přínosy. Jinak budete klasicky fungující organizaci přesvědčovat jen těžko.

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.

Role testera v agilním týmu

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

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

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

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

Shu-Ha-Ri aneb návrat k základům

Agilní metody upadají více a více do vlastní pasti zdánlivé jednoduchosti. Jak se všeho co je agilní chytá více lidí, stává se z agilních metod běžná praxe, kterou se ohání kde kdo. A tak to přeci nemůže být složité, že. Ostatně co je na agilním manifestu nového. Jsou to staré známé věci, které se zdají být zřejmé až do té doby než se je pokusíte použít. A tak hned jak se vám něco z toho co Agile doporučuje nezdá, změníte to nebo rovnou vyhodíte.

Jenže ona složitost agilního světa je ukryta někde zcela jinde. Musíte tomu porozumět, musí vám to přejít do krve jako metoda, styl řízení, jako způsob jak organizovat lidi. A právě tady je ukrytý problém. Aby se tak stalo, chce to cvik. Opakující se dril. Zpět k základům. Držet se daných pravidel a nezkoušet je hned v začátku měnit. Poslední dobou slýchám čím dál častěji na různých workshopech a konferencích skloňovat japonský princip učení se: Shu-Ha-Ri. Na to abyste se stali masterem, musíte postupně projít jednotlivými stupni. Ale to si většina Scrum Masterů, týmů ani managerů neuvědomuje. Je to moc práce, a oni už jsou zkušení, certifikovaní, tak proč začínat od začátku. Agile je přeci tak snadný. Selský rozum. Tak co, upravíme si to rovnou.

Jak se tedy podle japonských mistrů stát masterem? Shu je pro začátečníky. Je to čistý dril jako v armádě. Držte se pravidel, neměňte je, a snažte se je dělat pravidelně, správně a v plné kvalitě. Nepřemýšlejte o možných odchylkách, držte se doporučených principů a pravidel. Jak dlouho? Nebudou to ani týdny, ani měsíce. U takového Agilu a Scrumu to mohou být klidně tři roky. V druhé fázi – Ha – už máte sice základní principy zažité a začínáte se dívat na různá další doporučení a možnosti jak tyto další cesty implementovat, ale pořád ještě nejste experty kteří si pravidla mění a vymýšlí nová. 

Poslední fáze Ri je je pro ty, kteří už se nepotřebují učit od jiných jak mají danou věc dělat, a jsou schopni si vytvářet své vlastní teorie, principy a praktiky. Učí se z vlastní praxe. Bohužel, většina týmů ač ve fázi Shu, je skálopevně přesvědčena o tom, že je dostatečně zkušená na to, aby vymýšlela vlastní Agile a Scrum. Věří, že již dávno dosáhli Ri. A když by to náhodou nefungovalo, tak je to vina Agilu samotného. Prostě Agile ani Scrum není pro nás. Je na to jednoduchá pomoc. Vrátit se k základům, a jít cestou drilu jednoduchých základních praktik a postupného pochopení a vstřebání agilního přístupu. Není to ani Ri, ani Ha ale Shu. To je ale spousta práce a vyžaduje hodně trpělivosti. A to se v dnešním rychle běžícím světě špatně hledá. Ale bez toho se jen těžko stanete úspěšnými a Agile pro vás bude jen další teorie, která stejně jako ty předtím, prostě nefunguje.

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.

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