Tag: Scrum

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

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

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

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

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

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

    PF2014

    Další rok máme za sebou. Připadá mi, že Agilní metody se přeci jen pozvolna stávají běžnou součástí nejen projektového řízení a IT, ale že výhody tohoto přístupu pozvolna poznávají i produktoví manageři, business, a liniový management. Což je jistě dobrá zpráva.

    Na druhou stranu stále více se ukazuje, jak je těžké agilní přístupy, Scrum, Kanban, … aplikovat bez někoho s osobní znalostí agilní kultury. Někoho kdo v agilním světě žil a chápe proč jednotlivé praktiky fungují a jak do sebe zapadají.

    Samotné praktiky a plánované meetingy vás nespasí. Ani Standup meetingy, ani tabule s lístečky, ani User Story, ani to že requirementy nazvete Backlogem. Bez pochopení agilní kultury vznikne v nejlepším případě něco, co můžeme nazvat např: ‘technický Scrum’. Vypadá to jako Scrum, ale není. Při troše štěstí vám tyto kosmetické změny pomůžou a vy se uspokojíte. Není to sice bomba, ale je to lepší když teď spolu komunikujeme. Při troše smůly vám takto nasazené agilní metody, Scrum, Kanban, nepřinesou zhola nic, snad jen s výjimkou otravných meetingů, zbytečné byrokracie a nesmyslných pojmů.

    Přeji vám všem, aby se vám nasazení agilních metod dařilo a ten rozdíl proti starému neagilnímu světu byl výrazný a k lepšímu. Pěkný rok 2014.

    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.

    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 Prague Conference je již za pár dní – 16-17/9/2013 …

    … a tak je na čase napsat, na co se můžete letos těšit. Ale než představím program, sluší se pro ty co konferenci neznají, představit i Agile Prague. Agile Prague Conference je první mezinárodní konferencí zaměřenou na agilní metody v Praze a tradičně patří mezi špičku co se programu týče. Je to již tradičně dvoudenní akce, kde se ve dvou paralelních sekcích dozvíte vše o Agilních metodách, Scrum procesu a Kanbanu, co jste chtěli vědět. Letos pořádáme již třetí ročník, a stejně jako předchozí roky počítáme s účastí přes 200 účastníků. A proč zahraniční? Protože český a slovenský trh je malý a naplnit kvalitní program z pouze lokálních speakerů není v zájmu kvality akce vůbec možné. To ale zdaleka neznamená, že jsme nedali prostor firmám působícím na českém trhu. V sekci praktických case-studies se s vámi o zkušenosti se zaváděním a aplikací agilních metod, Scrumu nebo Kanbanu podělí téměř výhradně zástupci lokálních firem.

    A teď již k programu 2013. Na úvod, museli jsme změnit prostory, přesídlili jsme se do sousedního OK Systému, od čehož si slibujeme větší přednáškové prostory a také lepší spolupráci s provozovateli. Díky tomu jsme byli schopni rozšířit dvě zmíněné přednáškové sekce o třetí, ve které pořádáme v odpoledních hodinách Open Jam session, kde máte možnost sami navrhnout téma a diskutovat ho pak ve skupinkách. Druhým podobným slotem je Coaching Clinic, kde budete mít možnost nechat si poradit od agilních koučů, alias našich speakerů v podstatě s jakýmkoli problémem, který ve firmě řešíte. Do této třetí sekce jsme zařadili i novou deskovou verzi Scrum hry – Tulming Travel Game, takže když už budete unaveni z přednášek, pojďte si s námi hrát. Kapacita je omezená, tak přijďte včas.

    V hlavním programu jsme i letos získali hvězdy agilního světa jako je David Hussman, Scott Barber, Kevlin Henney a nebo Pat Guariglia. David má letos i jednodenní tutoriál, který byste si neměli nechat ujít – Agile Product Design. Nechci vypisovat celý program, ale namátkou – Johannes Broadwall ukáže remote pair programming, Uri Nativ se zaměří na QA, Fred Williams na psaní User Stories, Gustav Bostrom na TDD, Andrea Provaglio přijede do Prahy již počtvrté, tentokrát s přednáškou Dreaming, Angel Medinilla vysvětlí roli Scrum Mastera, a spousta dalších, kteří budou mluvit o konkrétních praktikách, zkušenostech, Scrumu, Kanbanu, agilní transformaci… Ostatně přijďte se podívat. Taková příležitost se nebude hned tak opakovat – až zase příští rok – 15.-16. září 2014.

    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 🙂