ScrumMaster není zodpovědný za delivery

Jedním z hlavních problémů, který blokuje ScrumMastery, aby ukázali organizaci svoji hodnotu je, že se nikdy nezbavili pocitu, že jsou zodpovědní za delivery. Pořád mají pocit, že když je tu problém, musí ho vyřešit. Pořád žijí ve světě projekťáků, asistentů, maminek. A firmy je v tom utvrzují tím, že je pasují do rolí delivery managerů, Project managerů se Scrumem a podobně. Takové lidi agilní týmy nejen že nepotřebují, ale jsou řekla bych až kontraproduktivní.

Cílem ScrumMastera není řešit, ale postavit dobře fungující samoorganizované týmy. Týmy, které jsou schopné si převzít za své problémy a rozhodnutí vlastnictví a zodpovědnost. Týmy, které se neustále zlepšují, pomáhají si. ScrumMaster, který týmu nedá prostor udělat chybu a poučit se z ní, dělá týmu vlastně takovou medvědí službu.

Takže jestli chcete mít dobře fungující Scrum, sežeňte si ScrumMastera, který tohle chápe. Být ScrumMasterem je leadership role. Skvělý ScrumMaster umí stavět highperforming týmy ze skupiny jednotlivců, umí lidi pro agile a Scrum nadchnout, protože staví prostředí s energií, motivované, dodávající organizaci hodnotu. A pro to platí jedna pre-requisita. ScrumMasteři musí mít agile a Scrum rádi, musí mu sami věřit. Je to vidět i na mých kurzech. Nejtěžší není lidi naučit Scrum framework. Nejtěžší je předat jim jiný styl myšlení a předat jim víru, že to dokážou.

Agile funguje, agilní týmy dodávají organizaci více hodnoty než ty neagilní. Scrum funguje, dává všemu energii. A jestli máte pocit, že u vás to tak není, nebojte se mi ozvat a říct si o pomoc. Často pohled zvenku vidí víc než ten zevnitř.

Podpořte svého ScrumMastera – kupte mu Vánoční dárek

Začíná čas adventní a blíží se pomalu Vánoce a ze všech možných zdrojů se můžeme dozvědět, jaké dárky pořídit manželovi/manželce, příteli/přítelkyni, rodičům, prarodičům, dětem. Ale na ScrumMastery jako by se zapomnělo, mi tedy přijde. Nikde jsem neviděla tipy na dárky pro ScrumMastery a tak jsem se to rozhodla napravit 🙂 Tak to berte jako oddychový předvánoční blog post s trochou reklamy, která se třeba může někomu hodit.

Základem dobré práce jsou znalosti a zkušenosti. A jedním z možných zdrojů jsou knihy. Doporučím svoji knihu The Great ScrumMaster: #ScrumMasterWay, protože si myslím, že se fakt povedla a hlavně mám na ni dobré feedbacky. Hlavně tím, jak je praktická a jde k jádru věci. Pokud někdo v Agilu tápe a chce širší rozhled, tak v češtině má prvotina Agilní metody řízení projektů je stále uceleným zdrojem informací. Pokud nevadí angličtina, určitě za zmínku stojí Essential Scrum od Kennetha Rubina. Pokud se chcete posunout dál, tak doporučuji Coaching Agile Teams od Lissy Adkins, která je skvělá koučka. Kniha trochu hutnější, ale už se nejedná o basic úroveň. A pokud se chce někdo posunout do multitýmového prostředí, tak kniha o LeSSu Large-Scale Scrum: More with LeSS je ‘must’ – obsáhla, dlouhá, informačně výživná. A Craig s Basem jsou prostě skvělí Scrum a LeSS traineři, od nich je radost se učit.

Pokud vás čtení nebaví a máte radši informace získané rychleji i s praktickou ukázkou, přijďte na školení. Pro ScrumMastery je určitě základem CSM – Certified ScrumMaster, kde se dozvíte jak se v roli ScrumMastera posunout dál a navíc získáte certifikaci, které má fakt hodnotu. Pokud CSM už máte či vám přijde, že to je moc basic (ale to moje fakt není) tak přijďte na Certified LeSS Practitoner školení, kde se ve 3 dnech dozvíte jak na scaling, produkty atd. Super advanced školení. A pokud chcete mít náskok a z role ScrumMastera se posouváte dál a potřebujete se na organizaci dívat více z managerského pohledu, tak CAL1 – Certified Agile Leadership bude přesně pro vás. Pokud by vás něco zaujalo, termíny najdete zde.

Inspirativní může být i návštěva konference, kterých je po světě hodně. Za zmínku určitě stojí Global Scrum Gathering, který bude v Londýně na podzim 2018, což je kousek, a pak samozřejmě moje nejoblíbenější Agile Prague 2018 (10.-11. září 2018), která je ještě blíž 🙂 .

Tolik mých pár Vánočních tipů z našeho nejbližšího okolí.

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

Nešvary a nepochopení Standup meetingu

Standup meeting je tak jednoduchý, že by se dalo říct, že je zbytečné o něm psát blog. Ale čím víc týmů vidím, tím důležitější mi přijde si to celé zopakovat.

Nešvar 1: ScrumMaster meeting řídí

V praxi taková věc má různé podoby. Začíná u čistého zahájení meetingu jako třeba “tak pojďme začít“ – jako kdyby tým nevěděl, že je potřeba aby někdo začal. Další nešvar je vyvolávání jednotlivých lidí a nutkavá potřeba je provázet těmi třemi otázkami. A končí to někde u pocitu že ScrumMaster je tu od toho, aby odešel s úkoly a udělal zápis.

Co má správně dělat ScrumMaster je ale pravý opak. Vysvětlit týmu, že to je jejich meeting a nestát jim dál v cestě. Být přítomný a naslouchat, být připraven facilitovat kdyby to bylo třeba, ale jinak je nechat Standup řídit. Je to tak triviální meeting, že to poběží samo už v druhém Sprintu.

Nešvar 2: Je to status

Standup jako status meeting vychází ze zažitých zvyklostí. Statusy jsme dělali vždy, tak co by tenhle divnej meeting byl. Tým se necítí být vlastníkem, a hledá někoho, komu by reportoval. Většinou se té role ochotně ujme ScrumMaster, v některých případech i Product Owner. Vedlejším efektem je, že členové týmu mají pocit, že musí jít do detailů a vysvětlit, na co vše narazili.

Když se budete řídit doporučením v předchozím bodě a nebudete stát před tabulí uprostřed a poutat na sebe všemožně pozornost, poběží meeting sám.

Nešvar 3: Co jsem to všechno dělal

Když začnete hledat, jak má Standup vypadat, doberete se obvykle třech otázek: Co jsem dělal, co budu dělat, a problémy. Klasický průběh je pak obvykle plný vyprávění, co všechno jednotliví členové dělali a jak strastiplný byl jejich den.

Ale to není to, co nás tady zajímá. Správný formát Standup meetingu je ,co jsem dokončil, co dokončím a identifikace problémů. My totiž věříme, že členové týmu strávili svůj den smysluplně. Není to kontrola, jen rychlý check jak stíháme. Tak rychlý, že do maximálně 5-ti minut jsme hotovi.

Nešvar 4: Nepochopení cíle

Zkuste se členů týmu zeptat, co je cílem Standup meetingu. Obvykle se dozvíte, že odpovědět na tři otázky, co jsme dělali, budeme dělat a identifikovat problémy. Nebo status a reporting. V lepším případě aby ostatní věděli, co jsem dělal a jak na tom jsem. To všechno je maximálně to co na Standupu děláte, ale ani v nejmenším to neodpovídá na otázku proč. A pak se často dostanete do problému, kdy tým říká “Jak teď sedíme spolu, je zbytečné Standup dělat. Řekneme si to vše během dne, přeci s problémy nebudeme čekat na Standup.“ A oni mají pravdu, že?

Jenže ono sdílení informací není cílem, jen prostředkem k rychlé odpovědi na otázku ’Stihneme dokončit, co jsme slíbili – tedy všechny položky Sprint Backlogu v dané kvalitě?‘ A jestli ne, co musíme udělat, abychom toho stihli maximum. Je to takové to pravidelní zastavení se, zamyšlení se jestli chceme něco změnit nebo pokračovat a jedeme dál. Proto se tam žádné detaily neřeší.

Na závěr: Standup je ideální místo kde můžete začít svou cestu ke Scrum 2.0. Tedy nejen naoko přejmenovat staré meetingy a role na nové a navlíknout trička my jsme Scrum tým, ale začít s opravdovou změnou mindsetu, přístupu a kultury. Protože to je teprve ten pravý Scrum.

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.

Planning meeeting na 30 minut – část 2

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

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

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

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

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

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

Planning meeeting na 30 minut – část 1

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

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

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

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

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

Certified Scrum Master kurz CSM poprvé i v češtině, aneb jak se to stalo

Byla k tomu dlouhá cesta. Někdy před rokem jsem se potkala na Scrum Gatheringu v Indii s Bobem Hartmanem, který zastupoval na konferenci Scrum Allianci. Část konference party jsme diskutovali o tom, že Scrum Alliance chce změnu, že se chce více otevřít novým lidem, nebýt už tolik tím uzavřeným elitním klubem, co mezi sebe nepustí nikoho nového, bez ohledu na to, jestli je člověk dobrý či ne. A tak jsem si říkala, že je asi na čase to zkusit. Využila jsem pro to jejich provisional CST proces. A začala sepisovat žádost, takový aplikační balíček. Byla to docela legrace. Bylo toho opravdu hodně a bylo to hodně detailní. Zkušenosti, doporučení, cotrainingy, mentoring… Když to zkrátím, trvalo téměř rok, než jsem se dopracovala k interview a po pár dnech čekání na výsledek to tu bylo. Nejdříve PCST – tedy Provisional Certified Scrum Trainer. A krátce na to Certified Scrum Trainer – CST. O co těžší a méně přehledný ten proces byl, asi o to větší z toho mám nakonec radost.

Proč byste měli chtít CSM certifikaci? Neměli. Žádná certifikace z vás odborníka neudělá. A certifikační kurz není nutně v ničem lepší než ten bez certifikace… Ale pro spoustu lidí je to určitý krok dál. Někde si ho odškrtnou ve svém vlastním interním rozvojovém plánu. Já vlastně nikdy certifikace nechtěla a dostávala je tak trochu náhodou… ve správný čas na správném místě. A překvapivě je nikdo nechtěl ani po mně, což mě vždy udivovalo. A proč jsem se tedy do toho celého kolotoče se Scrum Alliance a CST tedy pustila? Asi abych si dokázala, že na to mám. Přišlo mi trapné říkat, že nepotřebujete certifikaci, stačí vám můj necertifikační kurz, ale žádný certifikační kurz sama nenabízet. Je to jako ta bajka o lišce a hroznech vína. “Stejně jsou kyselé,” říká liška, když zjistí, že ani omylem na žádný hrozen nedosáhne. A tak jsem si říkala, že nechci být jako ta liška. A proč zrovna Scrum Alliance a Certified Scrum Trainer (CST)? Asi že není snadné takovou CST certifikaci dostat. Tyhle hrozny se prostě zdály být nejvýš. Tohle všechno jsou asi často motivace lidí jako jednotlivců. Jako důvod můžete přidat lepší šanci uspět u pohovorů, ale to stejně v praxi moc nefunguje.

Proč ale firmy chtějí certifikaci? Asi abyste jako firma dodali celému procesu důležitost, my to opravdu myslíme vážně, a opravdu Scrum chceme nasadit. Vidíte? Anebo abyste svým novým Scrum Masterům pomohli vytrvat, vydržet všechna ta příkoří a složitosti, kterými si při Agilní transformaci musí projít, zvednout jim sebevědomí, že to dokážou. Zvládnou to, mají přeci certifikaci. To oni jsou ti, kteří znají Scrum a pomůžou vám ho nasadit a adaptovat tak, aby fungoval. Když se nad tím zamyslíte, asi na tom něco je.

Takže jestli žádnou certifikaci nechcete, je to fajn. Váš Agilní život nebude o nic méně úspěšný. Tedy za předpokladu, že se nestěhujete třeba do Indie, kde každým získaným certifikátem významně stoupá společenské postavení jednotlivce. Ale jestli vás certifikace láká, teď máte první a jedinečnou příležitost absolvovat CSM – Certified ScrumMaster kurz nejen v angličtině, ale i v češtině.

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.