Tag: scrum master

Co agile očekává od Managera?

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

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

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

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

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

Proč je Sprint Burndown omyl

Slíbila jsem vysvětlení, proč je Sprint Burndown zbytečným overheadem a co dělat namísto něj. Tedy začněme tím, co by mělo být cílem – a tedy poznat, jestli tým ještě stihne dokončit User Stories, ke kterým se v rámci Sprintu zavázal. Tedy všechno, co je ve Sprint Backlogu. A to co nejjednodušší cestou. Bez zbytečných věcí. Když jsem nad tím přemýšlela, došla jsem k závěru, že většina lidí Sprint Burndown používá prostě proto, že nástroj který si koupili ho umí vykreslit. Tedy upřednostňují nástroje a procesy před lidmi a vztahy mezi nimi. Hned první věta agilního manifestu 🙂
Ale řekněme, že tohle není váš případ, že byste opravdu jen rádi věděli, jestli tým Sprint Backlog dokončí včas. A tak jste si začali takový graf kreslit ručně. A ejhle. Jak takový graf obvykle vypadá? No třeba takhle. Tým pracuje na mnoha User Stories najednou, a než dokončí první, je tu konec Sprintu. A když se Scrum Master v polovině Sprintu zeptá, jestli stihneme všechny User Stories ze Sprint Backlogu, dostane se mu obecného ujištění ve stylu “no jasně”. Nicméně z výše zmíněného Burndown Grafu to vidět není.

Možná namítnete, že váš tým přeci jen něco v průběhu dokončí, pak situace vypadá asi tak takto… ale to v reálu na věci nic nemění. Nezbývá než si držet palce. Nic o výsledku nám takový graf neříká. Jen ukazuje na fakt, že nic nevíme.

A někde tady se rodí myšlenka implementovaná mnoha nástroji, že je pro Burndown graf třeba trackovat jednotlivé úlohy. A abychom měli přehled, začneme je ohodnocovat v čase. Ale pozor, není čas přesně to, čeho jsme se v rámci agilních přístupů snažili zbavit? Na co pak ohodnocujeme v bodech, když tým vzápětí vracíme do světa man-days a hodin? Odhlédneme-li od toho, že založit úlohu v systému stojí nemalý čas týmu, který se členové týmu snaží minimalizovat tak, že zakládají relativně velké úlohy, aby je pak nemuseli měnit, nebo dokonce zahodit. A tyto pak odhadují v hodinách a své odhady kolik času zbývá, každý den mění. A překvapivě, jsme na tom obvykle ještě hůř, než bez takových odhadů. Většinu času si myslíme, že je všechno v pohodě, a ejhle, ono nebylo. Může za to mnoho faktorů, psychologie a optimismus vývojářů či testerů je jedním z nich. Už je to přeci skoro hotové.

No a teď už zbývá jen jeden krok – tedy místo nějakých odhadů prostě jen měřit čas, který jsme na daných User Stories strávili, a ten v grafu zobrazit. A světe div se, dostaneme každý Sprint krásnou lineární křivku, kolik “hodnoty“ tým každý den vyprodukoval. O tom, kdy to bude hotové, takový graf neříká nic, ale zato pěkně vypadá, dá se hezky reportovat a tým může všem dokázat, že poctivě pracoval.
Takže co s tím? Daleko snazší metodou jak zjistit, jestli ještě stihneme dané User Story dokončit, je udělat dobrou a přehlednou Scrum tabuli. Tři sloupce – backlog, in progress, done. Přehledně označit, kdo na čem pracuje, a co je ještě třeba dokončit. Dodržovat best practice tak, že limitujeme work in progress, tedy rozpracovanou práci, snažíme se věci rychle dokončovat a aby to bylo pěkně vidět, rozpadnout User Stories na jednotlivé činnosti o velikosti cca jeden den. Přidat lístek s taskem trvá několik vteřin, zahození ještě méně. Je to snadné, rychlé, efektivní. I náhodný kolemjdoucí koutkem oka z takové tabule vidí, v jakém je to stavu. A to se může hodit. Ušetříte si kupříkladu otravné otázky Product Ownera, jestli to stihnete, ale hlavně, budete sami vědět, na čem opravdu jste. A abych vás nenechala bez návodu, o tabuli, jak ji používat, a jak má vypadat, napíšu zase příště.

Jak vypadá Scrum, jak Scrum Master, jak má Scrum Master motivovat tým a jak řídit produkt

Jsou to zdánlivě nesourodé otázky, ale dalo by se říct, že po shlédnutí příslušných videí budete vědět, jak vlastně agilní metody fungují.

Jak vypadá Scrum?

Začneme krátkým úvodem Scrum ve 13s.

Že jste se toho moc nedozvěděli? Pusťte si video ještě jednou, a zjistíte že Scrum je iterativní proces, v každém cyklu dodává nějakou část, která má hodnotu. Zjistíte, že existuje něco jako Product Backlog, ze kterého se před každou iterací vybere pár celků, které tým v jednotlivých dnech zpracovává a které na konci iterace dodá jako hotové a nasaditelné. Na dokončené kousky se dívají ti, co k produktu mají co říct, tedy zákazníci, business, uživatelé a z jejich zpětné vazby vznikají požadavky na změnu, nové funkcionality, či funkce které můžeme oželet a ty se hned promítají do Product Backlogu. To je na 13s vaší pozornosti informací až až.

Kdo je to Scrum Master a jak spolupracuje s týmem?

Video má tentokrát asi 5min a uvidíte v něm jak se Ian jako “Super Scrum Master“ stará o svůj tým. Že byste to dělali jinak? Proč ne. Podstata je ale stejná. Všichni včas na Standup, nerušit tým změnou priorit, dodržovat done kritéria, brát testování jako součást úlohy. Scrum Master musí dělat to co je potřeba. Je coach a facilitátor. Je to o týmu. Ne o Scrum Masterovi. Ale bez dobrého Scrum Mastera nikdy nebudete mít dobrý tým.

Jak má Scrum Master motivovat tým?

A jak je téma složitější, prodlužuje se délka videí. Tohle je na přibližně 20min, ale opravdu stojí za zhlédnutí do konce. Přesně takhle totiž funguje motivace. Italy Talgam demonstruje na ukázkách různých dirigentů a orchestrů jak funguje leadership. Ve kterém orchestru byste chtěli pracovat? A který dirigent by byl dobrým Scrum Masterem? To určitě posoudíte sami.

Jak řídit produkt?

Poslední video je nejdelší, ale také je více nabito informacemi. Vytvořil ho Henryk Kniberg a myslím, že stejně jako jeho knihy Scrum and XP from the Trenches nebo Kanban and Scrum – making the most of both je i tohle velice pěkně vytvořené video kde se dozvíte vše co jste kdy potřebovali vědět o produkt managementu a roli Product Ownera.

Originál spolu s přepisem textu nejdete zde.

Konference Agile India 2012

Kolik z vás navštívilo konferenci zaměřenou na agilní metody v zahraničí, a kolik z vás v Indii? Cestuji ráda, takže se to zdálo být jako dobrý nápad. Navíc, chystala jsem se do blízké oblasti na dovolenou, tak proč ne 🙂

Jestli byste čekali, že Bangalore – Mekka IT outsourcingu – bude podobné moderním asijským městům jako Singapore, Kuala nebo Bangkok, tak to ani nápad. Žádná wifi, přelidněné město, všude smetiště a špína. Prostě Indie. Říkala jsem si tedy, že na konferenci uvidím ty IT odborníky, kterých má být Bangalore plné, a že třeba pochopím, proč si velké firmy vybrali pro outsourcing zrovna Indii. Myslím však, že to ani firmy samy nechápou. Jistě, je tu nízká cena. Ale ta je draze vykoupená nízkou kvalitou služeb a ohromným overheadem spojeným s řízením takto distribuovaného projektu.

Takže o čem se přednášelo? Základy, které i v zemích kde se s agilními metodami začíná už dávno znají. Tedy nic, co by stálo za zmínku. Témata, která se řešila, už byla zajímavější. Třeba že Indie je země s nejvyšším indexem “vzdálenosti od zákazníka” – tedy laicky řečeno, na zákazníka kašlou. A taky distribuované týmy a kulturní rozdíly. Zajímavé bylo, že Indové jsou přesvědčeni, že zákazník, když s nimi chce spolupracovat, se jim musí plně přizpůsobit. Třeba není vhodné od nich očekávat, že vám řeknou, jak se věci mají. Budou kývat hlavami, a to, že projekt má problém, se nedozvíte. Když na to jeden ze speakerů narazil, dostal udivenou odpověď z publika, že to je přeci v pořádku, oni si to mezi sebou poví, ale někomu cizímu, to přeci neřeknou. Další z legračních situací popisoval jiný speaker. Proškolili indickou firmu na Scrum, vše se zdálo být v pohodě, ale jen do té chvíle, než představili nové role. A kdy nový Scrum Master říká že se mu Scrum líbí, že mu rozumí, ale jestli si může dál říkat project manager, že by tím že je teď jen Scrum Master utrpěl jeho status a jak by pak před kolegy a rodinou doma vypadal…

Jak tedy chcete v tomto kastovním systému zavádět agilní metody založené na týmové spolupráci, zapojení zákazníka a transparentní komunikaci? Jak chcete dosáhnout self-organized týmu? Těžko. Někdo to na konferenci pěkně shrnul na twitteru: “Outsorcing v Indii je levná možnost jak nechat zkrachovat svůj produkt”. A asi s ním musím souhlasit. Ostatně většina firem už na to přišla také a tak Indii svěřuje v podstatě dva typy projektů. Výběhový SW, který sice musí udržovat, ale nejradši by se ho zbavili, a testování. Ostatně spousta firem netestuje vůbec, tak proč to nedat levně do Indie. I to má však jeden háček. Tím prvním můžete současné klienty odradit a přijít tak o více peněz, než by se z ceny outsourcingu původně zdálo. A co se kvality týče, jak chcete nechat testovat produkt lidem, kteří žijí v souvislém smetišti. Tester musí být precizní, vidět i drobné nesrovnalosti… A to lidé v Indii obvykle nevidí. Prostředí deformuje. Ostatně i mě po třech týdnech v Indii přišlo, že je tam uklizeno víc, než když jsme přijela… Na všechno si člověk zvykne.

Asi nejlepší byla přednáška o distribuovaných týmech kde Alexey Krivitsky pěkně popisoval jak se s takovým prostředím vypořádat. Doufám, že se nám podaří ho nalákat na konferenci do Prahy – AgilePrague, která bude 3-4. září, 2012.

Motivace

Jak efektivně motivovat zaměstnance? Je to jedna z nejčastějších otázek které dostávám hned po tom jak implementovat Scrum. Dobrý Scrum Master by měl umět tým motivovat. Být dobrým koučem. Takže jak na to? Určitě nepotřebujete žádný budget. To že peníze nejsou motivačním faktorem ale demotivačním – tedy ať přidáváte jakkoli, radost z vyšší mzdy či prémie vydrží tak týden. Pak zajdete na večeři, jedete na dovolenou a zas je to všechno jako dřív. Čím více dostanete, tím dříve si přijdete pro další. Ale dostáváte-li méně, než byste vzhledem k tomu co děláte měli, nebo než nutně potřebujete, za poměrně krátkou chvíli jste silně demotivováni. Takže řekněme, že plat je fér. Co ty nejlepší lidi vlastně v týmu drží a neodejdou ani za lepší plat jinam? Obava ze změny? Možná. Ale to nestačí. Dobrý kolektiv, smysluplná práce, pocit že to co děláte je potřeba, a že to má význam. A že to děláte dobře.

Tohle všechno samozřejmě není primární starostí Scrum Mastera. Má kolem sebe pár pomocníků.
Začněme tím co je starostí Product Ownera. Dodávat vaší práci smysl. Product Owner je vlastníkem produktu, potažmo product backlogu a ten musí tým nadchnout, aby ve svém počínání viděl smysl. Customer demo vám v tom jistě pomůže. Pochvala od zákazníka nikdy není k zahození. Pocit, že to co píšete někoho opravdu zajímá. A že to potřebuje. Takže by se dalo říct že Scrum proces vám s motivací také výrazně pomůže. Jestli tahle složka motivace nefunguje, jako Scrum Master to budete nejdříve muset spravit. Jinak práce bude těžko někoho bavit a těžko z kohokoli v týmu dostanete nějaké větší nasazení. Naopak uslyšíte samé výmluvy na okolí.

Takže produktu rozumíme, dává nám smysl, práce tým baví. Co zbývá? Scrum Master pomáhá odstraňovat překážky, tu šílenou práci co vás dřív obtěžovala… Občas pomůže moderovat diskusi, řeší problémy. To ale není vše. Měl by i lidi rozvíjet…

A tady začíná problém. Ve Scrumu by se dalo často říct, že tým je tak dobrý jak dobrého má Scrum Mastera. Scrum Master musí být v jistém smyslu i dobrý manager. Takový, co jednotlivým lidem v týmu věří, že dokáží být výjimeční a pomáhá jim stanovovat si takové cíle, aby byly náročné ale splnitelné. Aby tým pracoval nejlépe, jak umí. Špatný Scrum Master si jen stěžuje, že jednotliví členové nemají potřebné skilly, a že by se to museli učit. A na to že není čas. Dobrý Scrum Master ví, že tým to dokáže. Z hloubi duše jim věří a tým to někde uvnitř pozná. Aniž by taková informace byla kdy vyřčena nahlas. Jen tým pracující pod takovým Scrum Masterem může být ve skutečnosti úspěšný.

Na závěr doporučím jeden článek. Není sice o Scrumu, ale myslím, že dobrý Scrum Master musí vytvářet takový “pygmalion”.

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

Kdo je to Scrum Master? A kdo Product Owner?

Chcete vědět co je podstatou role ScrumMaster a ProductOwner v rámci Scrum procesu? Tady je stručné shrnutí těchto rolí.

SCRUM MASTER role

ScrumMaster především:

  • pomáhá týmu dosáhnout jeho cílů
  • odstraňuje problémy
  • motivuje tým k lepším výsledkům
  • chrání tým před vnějšími vlivy, které by ho mohly odvádět od soustředěné práce na definovaném cíli

Není to teamleader v klasickém slova smyslu, ale pracuje jako mezičlánek mezi týmem a jakýmkoli rušivým elementem zvenku.

Stará se o to aby Scrum proces byl efektivní a fungoval, má na starosti jeho dodržování, ale zároveň i možnost ho změnit je-li to třeba.

ScrumMaster by měl upřednostňovat koučovací principy, podporovat tým a jednotlivce v jejich rozvoji, být komunikativní, vnímavý a utlumovat případné konflikty v rámci týmu.
ScrumMaster role
ScrumMaster je ten, kdo se stará aby se “kola týmu točila” a který “zametá cestičku”, aby se týmu dobře šlo a pracovalo. ScrumMaster je součástí týmu a měl by být týmu kdykoli k dispozici. Sedí proto v jedné místnosti s týmem.

Funguje-li ScrumMaster dobře, nedá se jeho pozice chápat jako vícenáklad. To že rozpohybuje tým a zajistí tak vyšší efektivitu, kvalitu a motivaci v celkovém rozsahu ušetří vice peněz než ScrumMaster teoreticky stojí.

PRODUCT OWNER role

ProductOwner je vlastníkem produktu. Má na starosti definování vize projektu a její transparentní komunikaci týmu, zákazníkům, firmě. ProductOwner definuje priority, rozhoduje, na které funkcionalitě se bude pracovat dříve, na které později a na které vůbec. Má na starosti Business Value, a také ROI produktu.

ProductOwner je týmu pravidelně a podle potřeby k dispozici, ale na rozdíl od ScrumMastera už s týmem nesedí v jedné místnosti. Tráví dostatek času se zákazníky, aby vstřebal jejich prostředí a dokázal se vždy správně rozhodnout kde je pravá hodnota pro zákazníka.
Product Owner role
ProductOwner neřídí jednotlivé členy týmu ani tým, nemá možnost jim přikazovat, co musí dokončit, jen stanovuje, co se má dělat a v jakém pořadí (priority).

Primárním cílem ProductOwnera je tedy porozumění produktu, zákazníkovi a definice, komunikace, a jasné vysvětlení cíle, kam jdeme, proč a jak. A to jak týmu, tak managementu a zákazníkům. Cíl musí být pro všechny stejný, jazyk, kterým ho komunikuje, bude však odlišný.

Role by neměla být kombinována s rolí ScrumMastera.

Ne – certifikační kurz na Scrum proces?

Krize je pomalu za námi, firmy začínají zase investovat do vývoje nových funkcionalit a produktů a přemýšlí jak být rychlejší, flexibilnější, efektivnější. Jak být lepší než konkurence. A najdou agilní metody a Scrum proces. Ty organizovanější přijdou na to, že potřebují certifikaci, aby jim to opravdu šlo. Co je tedy certifikace v podání Scrum Aliance? Ty, co by čekali nějakou zkoušku či test, musím zklamat. Nic takového certifikace neobsahuje.

Na trhu jsou obecně k dispozici dva kurzy – Certified Scrum Master kurz CSM a Certified Scrum Product Owner kurz CSPO. Oba jsou velmi drahé. Důvodem je to, že takový kurz smí školit jen Certifikovaný trenér, a těch je vzhledem k procesu definovanému Scrum Aliancí relativně málo, a to i v celosvětovém měřítku. Důvodem je starost Scrum Aliance o kvalitu trenérů. Neříkám, že tito trenéři nejsou dobří, jen říkám, že i skvělého (necertifikovaného) trenéra z USA/EU seženete za polovic.

Absolvovala jsem CSPO, a určitě jsem se hodně dozvěděla. A určitě to mělo nějaký přínos. Očekávat ale, že tím že necháte přecertifikovat Scrum Mastera a Product Ownera zajistíte, že budou schopni zavést Scrum, je poněkud přehnané. Oba certifikační kurzy jsou jen dvoudenní kurzy, kde se účastníci něco dozvědí. O certifikaci jejich opravdových znalostí a schopností však nemůže být ani zmínka.

Máte-li pocit, že nevíte na koho z necertifikovaných trenérů a koučů se obrátit, a chtěli byste raději někoho z USA/EU, ráda vám někoho doporučím. Za stejný budget dostanete víc, než certifikací. A nakonec trváte-li na certifikaci, i mezi těmito trenéry jsou velké rozdíly.

No a pro ty, co nesměřují ani k certifikaci, ani nemíří do ciziny, můžu nabídnout své zcela obyčejné české kurzy Scrum procesu a agilních metod, na kterých se dozvíte vše, co potřebujete vědět o agilních metodách a Scrum procesu 🙂

Scrum proces není všemocný

Scrum proces se zdá být jednoduchou náplastí na všechny problémy. Nefunguje Vám tým? Začněte používat Scrum. Jste zahlceni byrokracií, Scrum Vás jí zbaví. Máte málo kvalitní kód, a pořád něco předěláváte? Netestujete? Zákazník není spokojen s tím, co dostal? Scrum má řešení. Tak se pojďme podívat, jak modelové firmy Scrum proces nasazují.

1. Technokrat s.r.o

Ředitel pověří někoho ze zkušenějších teamleaderů či vývojářů v týmu aby zjistili, o co jde. Ten si udělá research. Možná si koupí knihu, ale internet většinou stačí. Všechno umíme a víme, tak začneme. Scrum meeting (daily standup) je zdánlivě jednoduchý a chcete-li dělat Scrum, tak ho prostě musíte mít. Zároveň je ale třeba hledat tool, protože kartičky se používaly maximálně před sto lety. Čím složitější tool je, tím více možností má, ty všechny by se nám mohly hodit. A výsledek je, že tým brblá, že je to všechno k ničemu, proč tráví denně hodinu na meetingu který nic nepřináší, že své práce má dost. Toolu nikdo nerozumí, a Scrum metodě také ne. Navíc produktivita výrazně klesla a zákazník se také netváří nadšeně. Zeptáte-li se na Scrum metodu, dozvíte se, že Scrum my známe a děláme, ale my jsme v tom a tom jiní a pro nás se Scrum proces nehodí a nejde vlastně použít.

2. Developper s.r.o

Vývojáři o Agilních metodách nebo Scrumu nebo XP zaslechli někde od jiných týmů. A líbí se jim to. Nikdo by jim přeci nerozkazoval, nikdo by jim neříkal, co mají dělat a jak. Plánuje přeci tým, a to jsou oni. Cool. Tak začnou jednotlivé praktiky dělat. Většinou to selže v napojení na management. Někdy už na úrovni teamleadera, někdy až u top managementu. Spousta managerů v Čechách je ze staré školy. Bojí se dát své pseudozodpovědnosti na ostatní. Bojí se, že by někdo mohl vědět, co a jak dělají. A co se chystají dělat. A že by vše neměli pevně v rukou. A tak je lepší praktiky Scrumu omezit, okleštit nebo zakázat. Ale ne přímo, oni dělají Scrum, ale vidíte, dali jsme jim šanci, a ono to mělo takové problémy…

3. Korporát a.s.

Scrum proces a agilní metody používají velké firmy okolo nás. Měli bychom ho zkusit. Pošleme týmy na kurzy, project managery na certifikaci Scrum Mastera, a změníme procesy. Týmy tedy začnou, a až do prvního většího problému vše funguje. Pak ovšem project manager zapomene, že má jinou roli, a že jako Scrum Master nesmí měnit plán, nesmí rozhodovat za tým, a rychle se vrátí k osvědčeným metodám řízení projektů, na které byl zvyklý. A celá firma prochází deziluzí. Dalo by se říci, že devět z deseti project managerů se na Scrum Mastery nikdy nepodaří přeučit.

Existují i úspěšné firmy. Velké i malé. Ty většinou pochopili, že Agilní metody a Scrum představují změnu myšlení a přináší změnu kultury firmy. Investovali do kurzů, našli si interního či externího kouče aby jim s transformací pomohl. Vědí, proč změnu chtějí a co od ní očekávají. A vědí, že změna je náročná a vyžaduje hodně každodenní práce na každé úrovni. Taková změna nejde nařídit zhora, ani partyzánsky vybudovat odspodu. Musí propojit celou firmu. Stojí hodně energie. Ale výsledek pak stojí za to.

Co mi přineslo WebExpo 2010 – část 3

WebExpo, tedy agilní sekce konference o které teď volně píšu zážitky, mi přineslo i překvapení, že někteří z přednášejících berou agilní praktiky velmi striktně. Třeba Boris říkal, že ScrumMastera prostě musíte mít na full time na projektu. Zdůvodnění dávalo smysl, říkal, že ScrumMaster zefektivní tým o více jak 100% a tedy se ta investice hned zaplatí. Ovšem jeho odpověď na otázku co dělat když mám malý tým – radil, že mám dva týmy pracující pro různé zákazníky spojit do jednoho – mi už úplně realistická nepřipadala. Působilo to hodně procesně orientované, bez ohledu na realitu. Ideální svět neexistuje. Je dobré znát ideální řešení, ale je dobré ho i upravit když toto ideální řešení z nějakého důvodu nelze použít. Asi mi byl bližší přístup Davida, který říkal, že když praktikujete stand-up meeting, rozumíte jeho cílům, víte jak se má dělat, ale nepřináší vám očekávanou hodnotu, tak je pro Vás možná lepší ho nedělat vůbec, protože třeba není pro Vás.

Odhlédneme-li od spíše filozofické diskuze jestli se musíme spíše my přizpůsobit praktikám, či raděj přizpůsobit praktiky, Boris vysvětloval poměrně často zmiňovaný problém co dělat s tím, že některé úlohy potřebují nejprve strategicky rozmyslet a teprve potom se můžou implementovat. Následující obrázek ukazuje, jak se na danou problematiku můžete dívat z pohledu velocity. Jednou z možností je samozřejmě ohodnotit i tyto strategické práce, ale na druhou stranu, to že jeden den rozmýšlíte co dál, nemá pro zákazníka žádnou konkrétní prezentovatelnou hodnotu. A tedy je těžké to nějak ohodnotit. Proto mě zaujal princip navržený Borisem, který doporučoval počítat jen hodnotu pro features (zelená) a nikoli hodnotu kterou jsme věnovali strategickému rozvažování co a jak dál. Následující obrázek ukazuje, co mám na mysli.

StrategicAspects-Velocity

Na závěr dodávám, že se chystám na Borisem vedený certifikační kurz CPO – tedy Certified Product Owner, a jsem tedy docela zvědavá, co mi takový kurz přinese. Ale o tom zase příště.