Jak hodnotit ScrumMastera

Jedna z takových častých otázek je, jak na Performance review ScrumMasterů. Já si myslím, že to je vlastně od samého základu špatná otázka. Agilní organizace totiž od takzvaných performance review upouští a nahrazují je tzv. peer review, tedy vlastně otevřenou zpětnou vazbu od kolegů. Když se bavíme o self-organized a self-managed týmech, role managerů v celkovém fungování organizací se umenšuje a přechází na týmy. Ale to je asi na jiný článek. Cílem ScrumMasterů není týmu říct jak mají pracovat, nastavit iniciální proces a pak ho jen udržovat, což by šlo měřit a dát do cílů docela dobře, ale cílem ScrumMastera je neustále challengovat to jak pracují, pomáhat jim se zlepšovat, měnit a adaptovat na nové podněty a změny. To se ale špatně měří a tedy i hodnotí. Takže na co se máme zaměřit?

Jak tedy poznáme, že ScrumMaster funguje dobře? Často tak, že ho tým nepotřebuje a ScrumMaster má tak čas pomáhat organizaci na její agilní cestě. Umět postavit dobře fungujícího samoorganizovaný tým je totiž jenom začátek. Jeden agilní tým toho zas až tak moc nezmění. Abychom si rozuměli, jeden dobře fungující agilní tým má potenciál změnit životy jeho členů tak, že budou mít radost z dobře vykonané práce, budu mít dobrý pocit, že něco smysluplného vytvořili. Budou spokojeni a motivovaní a to je něco co stojí za trochu práce a energie. Dobře fungující tým bude mít také dobrý výsledek, budou dodávat hodnotu, mít spokojenější zákazníky. A to taky stojí za trochu práce a energie. Ale to je jen začátek fungování ScrumMastera v rámci #ScrumMasterWay modelu – Můj tým, kde je zajímavé se dívat, jak se tým zlepšuje, začíná si věci řešit sám a čím dál tím méně spoléhá na ScrumMastera. Jinými slovy, jestli je self-organized, cross-functional, a v krátkých cyklech dodává hodnotu zákazníkovi. Je dobré si při tom uvědomit, že ScrumMaster rozhodně nemá na starosti updatovat žádné nástroje (Jira, …), ani reportovat status produktu (velocity, story points, …), ani řídit a organizovat ceremonie (tedy eventy).

Většina organizací ale nemá tak malé produkty, aby je stačilo dodávat jedním týmem a potřebuje spolupráci více týmů, aby dodalo reálnou hodnotu zákazníkům. Určitě musí jednotlivé týmy fungovat dobře, aby měly dobrý výsledek, ale to je jen začátek. Je vhodné ho neodbýt, protože když nepostavíte dobře fungující self-organized, ale hlavně cross-functional týmy, tak se většinou jejich spolupráce stává noční můrou a nefunguje ať děláte co děláte.

K tomu, aby jednotlivé týmy spolu dobře fungovaly, potřebujete ještě zajistit, že i spolupráce mezi těmi týmy funguje dobře, tedy že se nezastaví na úrovni jednoho týmu, ale že se společně zlepšují, posouvají, hledají nové cesty a adaptují. Takže ScrumMaster, který nastavil fungování na úrovní jednoho týmu, si vlastně uvolnil ruce pro práci na větším celku organizace a jeho cílem je nyní pomáhat více týmům se samoorganizovat, a najít si lepší cestu jak budou společně fungovat a dodávat produkty. Tedy mluvíme o fungování ScrumMastera v rámci #ScrumMasterWay modelu – Vztahy, kde cílem ScrumMastera je podpořit spolupráci a samoorganizovanost tohoto většího ekosystému složeného z více spolupracujících týmů. Díváme se na to, jak se společně zlepšují, adaptují, přebírají zodpovědnost a vlastnictví. Tedy stávají se samoorganizovanými. Stejně jako v předchozím bodě je dobré si uvědomit, že ScrumMaster není jejich asistent, který má řešit závislosti mezi týmy (třeba na Scrum of Scrums, … ), ani dodávku produktu.

No jak asi tušíte, ten největší impact dosáhnete, když se posunete na úroveň organizace jako celku a pomůžete celé organizaci se zeštíhlit, descalovat, a pracovat jako spolupracující síť samo organizovaných týmů. Tedy mluvíme o fungování ScrumMastera v rámci #ScrumMasterWay modelu – Celý Systém, kde cílem ScrumMastera je pomoci organizaci změnit kulturu, leadership styl, a celkové fungování. V jednoduchosti aplikovat business agility. A asi nemusím říkat, že to není o aplikaci žádných frameworků.

Abych se obloukem vrátila k původní otázce, tedy jak na hodnocení ScrumMastera. Prvním bodem je identifikace, na které úrovni #ScrumMasterWay modelu se ScrumMaster primárně pohybuje. Následně se zaměřte na to, jak pomáhá týmům a organizaci převzít zodpovědnost za samo(organizaci), jestli #ScrumMasterWay modelem roste od úrovně Můj tým, přes Vztahy, až po Celý systém, a jestli se zaměřuje na neustálé hledání lepší cesty.

ScrumMaster není asistent, procesní policie ani maminka. Je to kouč a leader který dokáže organizaci změnit. Ale o tom zase příště.

ScrumMaster není asistent týmu

Když se podíváte na inzeráty hledající ScrumMastery, bohužel až příliš často najdete popis role, která místo ScrumMastera hledá spíše asistenta týmu. O tom, jak hledat ScrumMastera jsem tu už psala, takže dnes se podíváme na příčinu takového nepochopení. Jak vám většina lidí řekne, ScrumMaster má odstraňovat překážky. A pod tím si bohužel většina těch, co Scrumu a roli ScrumMastera nerozumí, představí právě toho asistenta. Takže co ta věta, že ScrumMaster odstraňuje překážky vlastně znamená? Pro porozumění se musíme vrátit k hlavnímu smyslu existence ScrumMastera. Cílem ScrumMastera je stavět dobře fungující samoorganizované týmy. A jak to, že týmu budete dělat asistenta pomůže týmu stát se selforganized? Nojo, nijak. Takže o čem to odstraňování překážek vlastně je? Překvapivě ne o tom, že je nebudete odstraňovat sami, ale že pomůžete týmu, aby si uvědomili, že si je dokážou odstranit sami. Tým je zodpovědný za to, že se zorganizuje tak, aby maximalizovali hodnotu vzhledem ke Sprint Goalu, tedy vlastní celý proces, a do toho patří i to, že se postarají, aby překážky nějak odstranili. ScrumMaster tedy není asistentem, ale servant leaderem. Pomáhá týmu převzít za své věci zodpovědnost a vlastnictví a stát se tak lepším týmem. Je coachem, pomáhá týmu si uvědomit kde problém je a jaké vidí možnosti řešení. A je facilitátorem, pomáhá týmu identifikovat příčinu a nevysilovat se řešením symptomů. Takže jestli jste si právě uvědomili., že většinu problémů za tým řešíte vy, vězte, že jim tím děláte medvědí službu a bráníte jim v tom, aby se stali lepším high-performing self-organized týmem. Zůstanou zaseklí tam kde jsou, a jen s tím, jak jde čas si začnou stěžovat, že oni za nic nemůžou a že to ScrumMaster měl… Není to moc pěkný obrázek. Dobrá zpráva je, že změna je snadná. Vysvětlete týmu, že dělat jim asistentky není vaším cílem ani zodpovědností a začněte více coachovat a facilitovat. Staňte se Servant leaderem, který věci za tým nedělá ani nerozhoduje, ale namísto toho vytvoří takové prostředí, že si je dokážou vyřešit sami. Občas to bolí, ale přináší to výrazně lepší výsledky.

Úspěšný ScrumMaster

Tipů, co dělat abyste se stali úspěšným ScrumMasterem je spousta. A spoustu jsem jich popsala ve své knize The Great ScrumMaster: #ScrumMasterWay. Ten nejjednodušší je být konzistentní. Věnovat se svému cíli – postavit ze skupiny lidí výborný tým, který bude self-organized, bude se neustále zlepšovat a posouvat na další a další level. Odolat pokušení vzít to zkratkou a za tým rozhodovat, odstraňovat za ně překážky a říkat jim co mají dělat.

Správný ScrumMaster je dobrým coachem, dokáže pomáhat týmu, aby si sami našli řešení a nespoléhali na nikoho třetího. Otevírá jim obzory. Není to asistent ani maminka, která se v dobré víře stará o své děti a chrání je tak, že nikdy nevyrostou. Nedopustí, aby se jim stala i drobná nepříjemnost. Dobrý ScrumMaster ví, že občas musí nechat tým spálit. Nechat je pracovat, jak říkají že je to nejlepší, a počkat až si sami vyzkouší jaké to je, když na konci Sprintu nemají co prezentovat. Snaží se tomu zabránit, ale občas jsou chvíle, kdy je potřeba je nechat zažít neúspěch, abyste na retrospektivě potom mohli přijít na to, co uděláme příště jinak, aby se nám to už nestalo.

Dobrý ScrumMaster je Servant Leader. Dělá ostatní lidi kolem sebe úspěšné.

Dělá z nich dobré leadery. Podporuje spolupráci v rámci organizace jako takové, podporuje self-organizaci, rozbíjí sila, staví komunity. Je to někdo, o koho se můžete opřít. Kdo vám pomůže postavit pravou Agilní organizaci a posílí kulturu spolupráce. Někdo, kdo vám pomůže být tou nejúspěšnější firmou a dosáhnout tam, kam byste se sami jen těžko dostávali.

Co dělá ScrumMaster když je tým samoorganizovaný

Dlouho mi vrtala hlavou otázka, co dělá ScrumMaster, když je tým samoorganizovaný. Když totiž přijmeme fakt, že cílem ScrumMastera je ‘nedělat nic‘, tedy že se nemá stát ani asistentkou ani maminkou týmu, ale nechat tým se sám organizovat, je tu problém. Co tedy budu dělat, až se mi to podaří? A protože to byla hodně častá otázka, tady je odpověď.

#ScrumMasterWay

#ScrumMasterWay je koncept, který jsem poprvé popsala ve své knize „Great ScrumMaster – #ScrumMasterWay“, která je dostupná pro Kindle formát na Amazonu a někdy během roku bude k dostání i v papírové podobě. #ScrumMasterWay je tedy odpovědí na otázku nejen co dál, ale i co že to vlastně je ScrumMaster.

#ScrumMasterWay: Můj tým

První úroveň je jednoduchá. Jmenuje se ‘Můj tým‘. V tomto vývojovém stádiu se ScrumMaster většinou stará o svůj development tým. Učí členy týmu pracovat ve Scrumu, společně zlepšují své procesy a praktiky. Tato úroveň je klíčová pro úspěch první etapy Agilní transformace. Cca za šest měsíců byste na této úrovni měli dosáhnout svého cíle a tým by měl být víceméně samostatný v rámci definice self-organized). Bez ohledu na to je ale i v pozdějších fázích transformace důležité se týmu a jeho rozvoji věnovat.

#ScrumMasterWay - MyTeam

#ScrumMasterWay: Vztahy

Druhá úroveň #ScrumMasterWay konceptu se zaměřuje na vztahy týmu s okolím. ScrumMaster už se nemusí tolik věnovat rozvoji týmu samotného, protože jeho členové už umí lépe komunikovat, spolupracovat a zlepšují se. V této vývojové fázi se ScrumMaster primárně zaměřuje na bezprostřední okolí development týmu. Jak funguje vazba týmu a Product Ownera? Jak zná zákazníka a chápe business value? Jak řídíme produkt a jaké metody Agile Product Ownershipu používáme? Jak si tým rozumí se svým managerem? A jak se nám spolupracuje s ostatními týmy? To všechno jsou otázky které vedou ke zlepšení okolí týmu a rozšíření principu samoorganizace na větší celek. V této fázi Agilní transformace obvykle nahrazujeme poslední zbytky tradičního mindsetu Agilní kulturou zaměřenou na spolupráci a převzetí zodpovědnosti. Za cca rok byste měli být na dobré cestě a mít čas se jistou část svého dne věnovat i třetí úrovni #ScrumMasterWay konceptu.

#ScrumMasterWay - Relationships

#ScrumMasterWay: Systém

Poslední úroveň #ScrumMasterWay konceptu je zaměřena na systém jako celek. ScrumMasteři se dívají se na celou organizaci nebo její část jako na systém a aplikujete koncepty jako system thinking, organization and relationship coaching, management 3.0, apod., aby self-organizaci rozšířili na úrovni organizace jako takové. V této úrovni je důležité se zaměřit na mindset, kulturu a hodnoty v rámci celé organizace. ScrumMasteři většinou pracují jako tým a dorostli do opravdových leaderů, kteří organizaci posouvají o stupeň dál.

#ScrumMasterWay - Entire System

Pohybovat se na všech třech úrovních #ScrumMasterWay konceptu je náročné. Je to hodně práce, která na ScrumMastera klade vysoké nároky, aby se stal enterprise Agile coachem, zlepšil se ve facilitaci, ale hlavně se stal leaderem, který organizaci posouvá dál. Ač na některých úrovních #ScrumMasterWay konceptu budete jako ScrumMasteři trávit většinu času, nezapomeňte, že ostatní úrovně jsou neméně důležité.

Jak poznat že se tým zlepšuje

Pro všechny managery, ScrumMastery a ostatní co se mě na to ptají.

Jestli čekáte, že vám poradím něco snadno změřitelného, tak vás asi zklamu. Tým se zlepšuje pokaždé v jiné oblasti. To nejde dopředu naplánovat. Na druhou stranu, jak to tedy poznáme? Není nad to jít se podívat. Prohodit pár slov. Do něčeho jen tak šťouchnout. Když to uděláte, zjistíte, že je zcela diametrální rozdíl mezi špatným týmem – který moc nefunguje, dobrým týmem – který tak nějak funguje, je ok, ale žádná sláva to není – a tím opravdovým týmem, který funguje skvěle – můžeme mu říkat třeba self-organized tým, Scrum tým, nebo high-performing tým. Dám příklad, o čem mluvím.

Ta úvodní věta, kterou tým polechtáte, může být třeba „ta tabule je dost k ničemu, nic z ní není vidět“… Nebo cokoli co vás zrovna napadne. Jakákoli ‘pitomost’.

‘Špatný tým‘ buď nereaguje vůbec, není to totiž jejich tabule, ani jejich rozhodnutí ji mít. Dělají jen to, co musí. V horším případě začnou na někoho ukazovat prstem, hádat se a říkat, že to oni nic, že to je vina kolegy, ScrumMastera, managera nebo Scrumu jako takového. Je to reakce malého řvoucího vztekajícího se dítěte.

‘OK tým‘ se většinou urazí, protože jak si někdo z venku týmu dovoluje nás kritizovat. Vždyť o nás nic neví. A buď vám vynadají rovnou, což je zdánlivě lepší varianta, protože máte jistou malou možnost to vysvětlit a začít diskusi, ale oni stejně většinou neposlouchají, tak to vyjde nastejno, jako druhá možnost, kdy si jdou následně stěžovat. Oni přeci jsou dobrý tým, všechno jim přeci funguje. Tak co? Je to reakce hodně frustrovaného labilního teenagera.

Je to analogie situace, kdy se jeden náš zaměstnanec rozčiloval, že nedostal prémie. On přeci vykonal všechno, co mu jeho vedoucí zadal. Tak na ně má nárok. Plní vše, co předpisy říkají. Ale to není to, co dneska firmy potřebují od svých lidí. Starají se o ně, dávají jim prostor, rozvíjejí je a očekávají, že budou takzvanými ‘kreativními workery‘, že u své práce budou přemýšlet a přicházet s nápady, jak to, co dělají dělat lépe. O tom je celý Agile a Scrum.

‘Opravdový tým‘ na takové šťouchnutí reaguje jako sebevědomý dospělý člověk, který se dříve nějak rozhodl, za svým rozhodnutím si stojí, ale není to žádný fanatik a rád se dozví, proč má někdo jiný názor. Je ochoten se nad tím zamyslet a ví, že pohled zvenku často vidí věci, které se lidem zevnitř staly neviditelnými. Obvyklá reakce je „no to je zajímavé, my si to nemyslíme, proč si to myslíš?“

Je to vstup do diskuse, kdy obě strany jsou ochotny si naslouchat a něco se dozvědět. Opravdový tým totiž ví, že ‘perfection‘ není stav, ale cesta. A v tomto kontextu vnímají i Agile a Scrum. Neustále hledají, jak se zlepšit.

Agilními ani ‘Scrumovými‘ se nemůžete stát. Je to přístup k životu, práci, činnostem. Je to kultura a filosofie. Stejně jako koupě růžence z vás neudělá věřícího, stejně tak ani Standup a Retrospektiva z vás neudělají Agilní firmu. Jsou to príma věci. Ale není to cíl, jen prostředek.

Jak tedy poznat že se tým zlepšuje? U prvních dvou je to jasné, dáte si pozor, že směřují o stupínek dál. Že z dítěte roste teenager, a z teenagera dospělý člověk. Co ale dál? Řekla bych, že když tohle pochopíte a máte opravdový tým, stane se tato otázka zbytečná, protože je to najednou jasné. Ale pro úplnost u dospělého opravdového týmu hledáme, jestli jsou lidi proaktivní, přicházejí sami s nápady, jak se zlepšit. Jestli mají jeden cíl, nebo bojují každý za sebe a jsou jen skupinou jednotlivců. Jestli vědí, proč se rozhodli tak, jak se rozhodli. Jestli jsou ochotni převzít ownership sami za sebe. Jestli jsou ochotni převzít plnou zodpovědnost (tak jak ji definuje Christopher Avery Responsibility process) za to, co dělají a nevymlouvají se, tedy zodpovědnost v kontextu co s tím uděláme my, aby se to příště nestalo, co změníme u sebe, jak budeme reagovat příště.

Na závěr varování: jestli z tohoto posledního odstavce uděláte tvrdé metriky typu KPI: A) Každý tým musí vymyslet tři zlepšení týmové práce za kvartál, dvě zlepšení na úrovni produktu a jedno na úrovni firmy. B) Každý člen se musí podílet na fungování alespoň jedné ‘improvement skupiny’. Asi nemusím dál pokračovat. Dopadne to stejně blbě, jako když za metriku kvality týmu použijete zvyšující se nebo striktně konstantní velocity. Zabijete poslední zbytky důvěry a veškeré pokusy o to, vytvořit normální prostředí včetně Agilu a Scrumu skončí neúspěchem.

Myšlenka na závěr… Nenapsala já jsem vlastně návod, jak zabít Agile a Scrum? 🙂 Možná, ale to už umíte i beze mne. Doufám, že vám to pomohlo.

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.

Procesy a metriky deformují lidi

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Všechno je o self-organized týmu

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

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

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

Pozvánka na konferenci Agile Prague 2011

Jak asi jako čtenáři tohoto blogu víte, pořádám v září konferenci zaměřenou na agilní metody. A protože jsem přes víkend napsala takovou pěknou pozvánku, přišlo mi škoda se o ni s vámi nepodělit. 🙂

Konference Agile Prague 2011

První mezinárodní konference zaměřená na agilní metody řízení proběhne ve dnech 29. – 30. září v Praze v konferenčním centru CITY na Pankráci. Přijďte se dozvědět něco nového. Buďte s námi agilní.

Co si představíte pod slovem Agilní? Dynamický, flexibilní, rychlý, mít schopnost reagovat na změnu, komunikovat se zákazníkem, ptát se po jeho potřebách. Pracovat jen na tom, co přináší hodnotu. V krátkých cyklech. Učit se, zlepšovat se, měnit sebe i svoje procesy… Je to pro vás něco nového? Nebo se již staly agilní metody nedílnou součástí nejen vašich projektů, ale i života? Ať již odpovíte na tuto otázku jakkoliv, konference Agile Prague je událostí, kterou byste rozhodně neměli minout.

Konference proběhne ve dvou dnech a dvou paralelně běžících sekcích, během nichž se vám představí 28 přednášejících z různých koutů světa, kteří se s vámi podělí o své zkušenosti s agilními metodami, Scrum Procesem, Extrémním programováním či Kanbanem.

Přemýšlíte, pro koho je konference vhodná? Pro vývojáře, testery, team leadery, managery, ředitele, majitele firem. Pro všechny, kteří se chtějí dozvědět něco nového. Pro všechny, kteří chtějí být efektivnější, flexibilnější, mít spokojené zákazníky, a v neposlední řadě chtějí, aby práce byla i zábava.

Začínáte? Říkáte si, co to vlastně ty agilní metody jsou, a jestli by vám to nemohlo něco přinést u vás ve firmě? Přijďte si poslechnout zkušenosti z firem, které v posledním roce na agilní metody přešly. V praktických case-studies se s vámi podělí o své zkušenosti. Co očekávali, co se jim povedlo, ale i co bylo těžší, než si mysleli, či co se jim stále nedaří. Zajímá vás, proč firma LMC začala se Scrum procesem a jak se změnili jako celá firma? Proč se rozhodli být agilní? Ondřej Mysliveček se s Vámi podělí o své zkušenosti z této změny. Nebo chcete vědět, jak se mění velká korporace jako T-Mobile, a co je k takové změně vedlo? Jindřich Otčenášek má s touto změnou čerstvé zkušenosti.

Jste součástí agilního týmu? Popovídejte si s J. B. Rainsbergerem (Canada) a určitě nevynechte jeho key-note přednášku, kterou uvádí slovy: “Každý měsíc se mě někdo ptá, jak přesvědčím svého managera, aby mi dovolili refactoring”. Pokračovat můžete přednáškou představující praktický úvod do Kanbanu, který uvede Joakim Sundén (Švédsko), poslechnout si, jak naložit s agilními metodami v oblasti UX, kde se o zkušenosti z Keria podělí Petr Douša, či se jít podívat na přednášku Tomáše Perglera jak se Scrumem naložili v Seznam.cz, nebo Pavla Teichmana na jeho zkušenosti z Pojišťovny DIRECT.

Pracujete pro státní instituce a nevíte jak, a jestli vůbec je možné agilní metody použít? Využijte jedinečnou možnost si poslechnout, jak s prostředím Evropské Komise, která si s ničím nezadá s českými státními institucemi, naložil Andrej Zachar (Simpleway) a Sjerk Van Riel z Belgie, nebo jak Pat Guariglia z USA nasadil Agile a Scrum do New York State Government Agency.

Jste Scrum Master nebo Product Owner? Nevynechte možnost poslechnout si zkušenosti jiných Scrum Masterů a Product Ownerů. Poslechněte si, proč Alan Bustamante považuje Agile jako “nejlepší způsob jak získat ze softwarových projektů nejvyšší hodnotu“, nebo si zahrajte na Scrum a postavte si s Thorstenem Kalninem letiště z Lega.

Vedete více týmů? Chtěli byste, aby byly efektivnější a motivovanější? Přijďte si poslechnout přednášku, kde Ola Ellnestam (Švédsko) bude mluvit o tom, co to znamená být agilní, Andrea Provaglio (Itálie) vysvětlí jak docílit samoorganizujícího (self-organized) se týmu a Chris Matts (Velká Británie) se zaměří na business analýzu v agilních týmech. Nakonec vám Alan Brown (Španělsko) z IBM poradí jak odolat tlaku na dokončení všeho ještě rychleji a levněji než doposud.

Vlastníte nebo řídíte firmu? Vidíte, jak se svět zrychluje, je dynamičtější a klade na Vás čím dál tím vyšší nároky? Máte strach, že neudržíte krok s konkurencí? Přijďte se podívat, co vám agilní metody mohou přinést, jak agilní metody komunikovat, jak je nasadit. Začít můžete hned na naší první key-note přednášce – Christopher Avery (USA) – Your Agile Leadership Gift. Určitě budete souhlasit, že komunikace je čím dál tím důležitější. A to jak v rámci týmu, tak i externě se zákazníkem, businessem či managery. Jak v praxi komunikovat si vyzkoušíte na interaktivní přednášce Zuzany Šochové a Eduarda Kunce.

Jste Agilní? A jen se chcete posunout trochu dál? Něco se dozvědět? Máte pocit, že Vám možná něco uteklo, nebo že potřebujete pár nových nápadů? Zapojte se do open-space diskuse, podělte se s námi o krátký lightning talk, nebo volně diskutujte s přednášejícími i účastníky v příjemných prostorách konferenčního centra na Pankráci.

Jsme rádi, že v rámci aktivit Agilní Asociace spolu s partnery můžeme agilní komunitě v Čechách přinést akci světového formátu. Akci, která pomůže širokému spektru firem být úspěšnější, akci, na kterou se budete těšit zase příští rok.

Těšíme se na setkání s Vámi.

Tým Agile Prague Conference

http://agileprague.com