Tag: Management

Deset let s Agilem

Kdo by to byl řekl, jak ten čas letí. Tuhle jsem si uvědomila, že to je 10 let, co jsem poprvé potkala Agilní metody. Vše se seběhlo rychle a jak už to tak bývá, tak to bylo hodně i dílem náhody.

Po návratu z dovolené v Etiopii na konci února 2005 jsem se dozvěděla, že za tři týdny odjíždím do USA k našemu zákazníkovi, firmě Medtronic (kdo Medtronic nezná, tak je to jeden z největších světových výrobců zdravotní techniky, fakt velký kolos, kótovaný na burze – MDT).  No a než jsem se rozkoukala, byla jsem v Minneapolis, kde má Medtronic headquarter. Spolu se mnou přijelo několik kolegů z Holandské pobočky a společně jsme se měli zapojit do týmů a pomáhat s vývojem aplikací pro kardiostimulátory a defibrilátory. Což je samo o sobě docela legrace. Jenže v Medtronicu v té době začala probíhat docela zásadní změna a to přechod k Agilnímu způsobu vývoje. A já jsem dostala šanci být u toho hned od začátku, takže tak trochu štěstí, i když v té době bychom to asi s kolegou úplně štěstím nenazvali. Šlo to rychle, v podstatně větším stylu než v nějaké malé firmě kde se o všem strašně dlouho diskutuje a řeší se, co by na to který developer či tester řekli. Ale zas na druhou stranu měli jasno v tom, proč to dělají, co očekávají a dali nám podporu výborného Agilního kouče. Začínali jsme rovnou aplikovat Scrum pro více týmů spolupracujících na jednom produktu, učili se spolupracovat, posilovali cross-functionalitu týmů, párově programovali, učili se jak nastavit continuous integration, aplikovali základní Extreme programming (XP) principy a později i Test Driven Development (TDD).

Po návratu do Prahy jsem měla za úkol postavit dva týmy a naučit je Scrum, aby spolupráce úspěšně mohla pokračovat. Tady se ukázalo, jak v různých kulturách jsou různé věci akceptovány různě. Ale po překonání úvodní nejistoty a resistence nám to docela fungovalo. Samozřejmě to prostředí mezinárodní spolupráce a life-critical segmentu nebylo snadné. Distribuované týmy, práce v různých časových zónách, synchronizace více týmů, spolupráce několika Scrum Masterů. Prostě komplexní prostředí, se všemi klady i zápory.

To že jsem se Agile a Scrum neučila v male firmičce či startupu o 10 lidech, ale ve velké korporaci se mi v podstatě hodí do teď. A bylo dobře i mít zkušenost z life-critical segmentu. Člověk si hned vyzkoušel, jak takové věci fungují ve složitém prostředí a následná aplikace na menší firmy už to vlastně všechno jen zjednodušovala. Byla to super škola a zkušenost.

Když jsem nakonec začala pracovat jako Agilní Coach ve své vlastní firmě, byly to zkušenosti k nezaplacení. Jak šel čas, pomáhala jsem malým startupům, firmám které rychle vyrostly, různým korporacím, produktovým firmám i společnostem dodávajícím služby v oblasti vývoje SW. V množství různorodých klientů byly i marketingové firmy, operations týmy, HW firmy. Pracovala jsem s distribuovanými týmy USA-Evropa-Asie. Takže 3 časové zóny a hlavně kulturní rozdíly. Přeci jen Vietnam či Indie je kulturně hodně odlišné prostředí a to se v implementaci Agilních přístupů projeví. I přes časté cesty do zahraničí mám stále většinu práce doma v Praze, hodně jsem i v Brně a na Slovensku.

S kolegy jsme před několika lety založili Agilní Asociaci (agilniasociace.cz), kde v rámci lokální Agilní komunity umožňujeme sdílení zkušeností z Agilního světa. Pořádáme pravidelná otevřená setkání tzv. open café a každoroční konferenci Agile Prague (agileprague.com). Ale tu určitě znáte – a kdyby náhodou ne, letos bude 14-15. září v Praze na Pankráci.

Sama se snažím hodně cestovat na různé konference, sbírat nápady jak pro týmy, kterým pomáhám Agilní metody pochopit, tak právě i pro konferenci Agile Prague. Jedna z nejzajímavějších zkušeností byla přednáška na konferenci Agile 2012 v Texasu – pravděpodobně největší Agilní konferenci na světě. Přednášela jsem i na několika Scrum Gathering konferencích, kde je většina přednášek praktická, formou mini-workshopů.  Své zkušenosti s Agilními metodami jsem se snažila shrnout v knize “Agilní metody řízení projektů”, která se během půl roku vyprodala, takže musel být vydán dotisk. Bylo docela příjemné zjištění, že ta kniha hodně lidem pomohla a často si ji chválí. V loňském roce jsem se zase profesně posunula dál, díky získání certifikace od Scrum Alliance – Certifikovaný Scrum Trenér (CST – Certified Scrum Trainer) tak mohu také školit certifikační kurzy, jako například certifikovaný ScrumMaster (CSM – Certified ScrumMaster). Nejde ani tak o certifikaci, které můžu školit, ale o možnost být součástí Scrum světové špičky. Začala jsem vlastně náhodou a jsem ráda, že se mi tím složitým procesem podařilo úspěšně projít.

Je to až neuvěřitelné, co se za těch deset let všechno událo. Za to, že se vše povedlo, ale musím poděkovat hlavně i vám všem, kteří jste mě během těch let pomohli – ať již jako zákazníci anebo kamarádi při některé z mnou/námi pořádaných akcí. Díky moc!

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.

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.

    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.

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

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