Chcete se jít podívat do Agilní firmy?

Tak pro vás mám návrh na výlet :). Pořád se mě na to někdo ptá, kam se máme jít podívat? Ono to hodně záleží, co chcete vidět, že. Ale mě se teď naposledy líbilo v této firmě v Ho Chi Minh City ve Vietnamu. Vietnam je krásná země s výborným jídlem, příjemnými lidi a zajímavou krajinou, takže můžete spojit výlet s trochou pracovní inspirace. Firma, ve které jsem se byla podívat se jmenuje Axon Active a dělají software na zakázku. Typická service organizace, o které mi zase v Indii kam teď mířím budou říkat, že agilní být z definice nemůže.

2018-08-17-10-13-16Každý tým je jiný, má vlastní styl práce a svoje vlastní hravé detaily, je také vidět, jak se od sebe různě inspirovali. Jak spolupracují. Asi nejlepší bylo vidět několik Product Ownerů co na týden až dva přijeli, aby byli s týmem, jak sedí v týmovém prostoru a společně řeší věci.

Je to takový collaborative space. Flexibilní uspořádání, které jim umožňuje týmy dynamicky rozšiřovat a růst jako firma. Všude po stěnách je vidět spousta aktivit. Teaching club, kde si můžete zkusit něco vysvětlit, knihovnu s knihami, které si vozí v kufru z Evropy, protože ve Vietnamu nejdou snadno koupit, pravidelnými agilními snídaněmi, tabulí s Kudo kartičkami, a tak bych mohla pokračovat. Ono se to nedá změřit. Je to o tom, co na vás dýchne ze vzduchu, když tam přijdete. Fotky z akcí, jména týmů, dekorace. Není to konkrétní seznam. Je to kultura a hodnoty. Určitě byste našli spoustu antipaternů, ale já v reálu myslím, že o to nejde. Je to o energii, kterou z prostředí cítíte. A jestli je pro vás výlet moc daleko, tak tady je pár fotek.

2018-08-20-18-21-25

2018-08-20-18-21-16

2018-08-20-18-21-06 2018-08-20-18-20-40

2018-08-20-18-20-27

2018-08-20-18-19-51

2018-08-20-18-19-40

Business Agility

V poslední době se mimo IT obor často skloňuje termín Business Agility. Co si tedy pod Business Agility představit? Já jsem se tady hodně věnovala Agilním metodám v IT tak, jak se s nimi začínalo. Ale doba se posunula, Agilní metody se osvědčily a tak více a více slyšíme o aplikaci Agile mimo IT, o zapojeni businessu, o aplikaci Agile na úrovni organizace. V kostce tedy Business Agility. Organizace hledají způsob, jak přistupovat ke svému businessu tak, aby byly flexibilní, efektivní a rychleji reagovaly na změny. Agile v rámci IT je jen částí úspěchu. Aktivní zapojení businessu a agilní strategické řízení firmy je důležité, aby organizace byly schopny efektivně přežít z dlouhodobého hlediska v prostředí, které je obecně globálně rychle se měnící, turbulentní a není tak předvídatelné, jako to bylo v minulosti. Nevěříte? Malá statistika: přibližně 70% společností, které byly v žebříčku Fortune 1000 před 10 lety, z něj zmizelo, nestačily se přizpůsobit změněnému prostředí – digitalizace, všudepřítomný internet, mobilita.

Adaptabilita, flexibilita a vyváženost jsou tři klíčové elementy Business Agility.

Business Agility je organizační změna, která funguje bez ohledu na podstatu businessu, kde organizace působí. Business Agility je vlastně Agilita z pohledu organizace jako celku, je změna kultury a fungování celé organizace, její schopnost se adaptovat, zregenerovat, rychle se změnit na základě vnitřních, ale hlavně vnějších změn. Není to ale žádný chaos, Agilní firma má na rozdíl od mnoha klasických firem velmi jasně definovaný směr. Funguje jako flotila malých lodí, které všechny plují za jedním cílem, ale mají v rámci své mise autonomní řízení. Řízení se stane daleko dynamičtější, než jsme zvyklí z prostředí ročních plánů, iterace businessu se točí v krátkých cyklech, základem všeho jsou samoorganizující se týmy, které samozřejmě obsahují business, přináší inovace a evoluce, ale také změnu leadershipu. Můžete namítnout, že to není nic nového. No není. Je to jen ten stejný Agile přefrázovaný do jiných slov, která jsou více uchopitelná businessem a managementem a má tím pádem potenciál transformovat firmu z úplně jiné strany.

A na závěr, co je opakem Agilní firmy? Firma byrokratická, hierarchická, procesní. Prostě firma s klasickým fixním řízením, pevnými strukturami, kde každá změna musí být schválena na vyšších úrovních a autonomie neexistuje.

Jak hledat ScrumMastera

ScrumMasterů je na trhu málo. O to méně je těch dobrých. Takže tady je pár tipů, kde lovit dobré ScrumMastery.

Zájem

Hledejte někoho, kdo má jiskru, kdo Agile a Scrum bere jako koníček. Ideálním místem jsou konference. Třeba AgilePrague Conference  je ideálním místem 🙂 Hledejte někoho, kdo se o Scrum opravdu zajímá, kdo čte knihy, píše blogy, nebo navštěvuje pravidelně Agilní setkání.

Přístup

Výborný ScrumMaster je Servant Leader. Někdo, kdo pomáhá ostatním stát se lepším, někdo kdo z ostatních lidí dělá leadery. Někdo, kdo „MY“ dokáže upřednostnit před „JÁ“. Není to asistent týmu ani maminka. Umí postavit dobře fungující tým, je dobrým koučem a facilitátorem, ví, jak se zavádí změna, umí stavět komunity v rámci organizace.

Znalosti

Ty se, i když by náhodou něco nevěděl, naučí. Ostatně vždy ho můžete poslat na Certified ScrumMaster kurz, nebo mu doporučit knihu The Great ScrumMaster: ScrumMasterWay :). Já se většinou na interview ptám, co je to Scrum, co je cílem ScrumMastera, a proč je to důležitá role. Ale na to většinou stejně nepřijde dobrá odpověď, a tak radši přejdeme k simulaci nějaké situace např: „Představte si, že jsme tým, který včera absolvoval školení o Scrumu. Moc se nám to ale nezdá a myslíme si, že to tedy rozhodně není pro nás. Co jako Scrum Master budete dělat“. Když si slepě vede svou, neprošel testem, protože neumí naslouchat, když začne koučovací otázkou, většinou uspěje.

Pokračovat můžeme složitějším příkladem, třeba otázkou na nějaký problém, co nejde nijak dobře vyřešit, např. „Tým má 2 dny do konce Sprintu a nic dokončeného. Tým je v pohodě a říká, že to stihne. Co uděláte?“ Jestli začne řešit za tým co mají dělat a převezme za ně zodpovědnost za dodání, není to správná odpověď. Když jim pomůže rozsah problému vidět a přijít na něco, co by s tím sami mohli dělat, vede to k větší self-organizaci a tedy správným směrem.

Na závěr můžete dát poslední case z venku týmu: „Přišel za vámi Product Owner, že neví, jak má prioritizovat Backlog o 3500 položkách. Co uděláte?“ Jediná rozumná odpověď je zkusit zjistit, jestli vize existuje a pomoct mu to postavit spolu s týmem znovu a pořádně. 3500 věcí je moc a Backlog bez Vize nemá smysl.

A tak bych mohla pokračovat. Ani nejde o správné odpovědi, ale o to, jak dokáže reagovat na překvapení, jak se v dané situaci chová, jestli vnímá signály, co mu dáváte nebo si jen mele svou, jak zareaguje když mu vysvětlíte, proč to není tak, ale jinak. Musí vás to bavit. A kandidáta také. Když se urazí, asi to není dobrý match pro vaši firmu.

Zapadne?

Poslední je asi rychlý check jestli zapadne do firmy. Ideální je den v týmu. Tým dá zpětnou vazbu, jak se mu ScrumMaster líbí a ScrumMaster si udělá představu do čeho jde. Některé firmy nabídnou jen oběd s týmem, jiné třeba jen procházku po prostorách. I ta je dobrá. Divili byste se, kolik se toho dozvíte za 10minutovou procházku po firmě.

Takže šťastnou ruku při výběru.

Agilní HR

Ještě před pár lety byl software na okraji zájmu. Business přeci žádný software nepotřebuje. A s výjimkou pár výstředních developerů, které firmy zavíraly někam do sklepa, IT nebylo v kurzu. Pak ale přišel internet a celá digitalizace a dnes si bez IT svět neumíme představit. IT projekty se stávají komplexnější a s trochou nadsázky se nedá najít firma, která by IT nepotřebovala jako nedílnou součást svého businessu. IT se dneska stává hlavním motorem businessu a úspěchu firem. A protože v IT světě převládají Agilní přístupy, začínají se tyto metody šířit i do jiných částí firmy jako je marketing, sales, business, ale také management a HR. Všichni potřebují efektivně pracovat v dnešním komplexním, neustále se měnícím světě, být flexibilní a dynamičtí.

Jak už jsem psala, pokud chcete opravdu změnit firemní kulturu a firmu posunout směrem k Agilní firmě – vybudovat Organizaci 3.0, nemůžete se zastavit na hranici IT oddělení. Je potřeba, aby i ostatní oddělení fungovala na stejné vlně. A to včetně včetně HR (tedy Human Resources). Zdánlivě to není velká změna, i v Agilní organizaci musí HR pomáhat s hledáním a najímáním zaměstnanců, vzděláváním, rozvojem lidí, atd. – ale najednou se nezaměřujeme na jednotlivce a jejich specializaci. HR musí umět najímat zaměstnance do týmů, schopnost týmové spolupráce, ochota učit se nové věci, a mindset je daleko důležitější než konkrétní znalost. Prostě musí zapadnout do firemní kultury. Do pohovorů často zapojujeme tým, a klasická individuální KPIs nahrazujeme týmovými cíli.

Mění se vlastně celý systém, kdy Agilní HR je tu pro své zákazníky. Tedy zaměstnance (všech úrovní) a ty vtahuje do svého fungování. A může HR použít třeba Scrum? No jasně, přestanou být operativními personalisty, a začne firmu pomáhat strategicky formovat. Jako vždy to začíná vizí. Čeho chceme dosáhnout, co nám to jako firmě přinese, kdo jsou klíčoví zákazníci, jaké máme persony. Jako součást visioning workshopů si stejně jako u produktu spolu s klíčovými stakeholdery postavíme Backlog – třeba formou Impact Mappingu nebo Story Mappingu, a uděláme ho transparentní pro celou organizaci. Tohle je klíčové a málo lidí to dělá. Typická konverzace se vyvíjí následovně. To je pěkný Backlog, je z něj vidět co děláte, a co se chystáte dělat. Můžeme ho dát někam, aby k němu měli přístup všichni a mohli se na něj kdykoli podívat? A vy máte i online Scrum Board, to je super. Můžete nám ho také ukázat? Reakce, jak sami tušíte, je většinou odmítavá. V lepším případě říkají, že tam je moc detailů, a že by to lidi stejně nezajímalo, ale že se nad tím zamyslí. V horším případě se dozvíte ostré NE, protože je to přeci tajné. Ale suma sumárum je za tím asi obava, že kdyby lidi věděli, co děláme, moc by nám do toho kafrali. Ale není to právě to, co chceme? Dostat feedback co nejdříve. Ne,až když je to celé hotovo, a je na něj vlastně pozdě.

Pět nejčastějších chyb Agilní a Scrum transformace

ScrumMaster řeší překážky, přece k tomu tady je. A když ne interní, tak alespoň externí. Kdo jiný by to přeci dělal, no ne? Vždyť jinak by tým nebyl efektivní.

ScrumMaster pomáhá týmu, aby si překážky odstranili sami. Facilituje diskuse, vysvětluje, coachuje a pozoruje. ScrumMaster State of Mind model je dobrým nástrojem jak na to.

Product Owner nemá být na retrospektivě. Moc by viděl, jak to děláme, a hlavně, moc by nám říkal, jak to máme dělat.

Product Owner je součástí Scrum týmů, jak jinak chceme takový tým postavit, když společně nepřemýšlíme, jak zlepšit spolupráci. Product Owner i Development tým mají jeden cíl. Dodat hodnotu zákazníkovi. Společně na tom pracují, pomáhají si a společně hledají kde se zlepšit.

Velocity a Story Pointy jsou hlavní metrikou dobré implementace Agilu. Velocity musí růst. Podle toho poznáme, že se zlepšujeme.

Agile a Scrum dávají důraz na dodání hodnoty. Story Pointy ale odhadují effort, komplexitu a risk. A to nemá s hodnotou nic společného. Určitě si umíte představit jednoduchou funkcionalitu, která přinese velkou hodnotu, a hodně komplikovanou věc, která bude mít hodnotu stejnou.

ScrumMaster by měl za tým řešit problémy. A protože to není práce na full-time, tak může být současně i členem týmu.

Cíl ScrumMastera je pomoci týmu se stát skvělým týmem. Takzvaně high-performing. Být self-organized. Nezávislý na ScrumMasterovi. Neustále hledat lepší možnosti, jak bychom mohli pracovat.

Naimplementujeme Agile a Scrum a je to. Odškrtáme pár praktik a jsme s Agilní transformací hotovi.

Agilní transformace je cesta. Cesta, kterou se učíte a neustále hledáte jiné praktiky, jak být lepší. Nikdy nebudete hotovi. Dělat Agilní praktiky nestačí. Musíte být Agilní a neustále hledat, jak se zlepšit. Vítat změny. Je to stav mysli, filosofie. Pokaždé, když dosáhnete svého cíle, který jste si na této cestě definovali, pokaždé se vám otevře obzor a vy uvidíte další nový svět kam se posunout dál.

 

Scrum pro distribuované týmy

Častou otázkou bývá, co s distribuovanými týmy. Takže začněme od začátku. Scrum funguje výborně pro co-lokované týmy. Tedy lidi, kteří sedí na jednom místě a spolupracují. Mají jeden cíl, pomáhají si. Jsou u sebe, a tak je snadné spolupracovat. Nemusí si plánovat žádný meeting, ani si posílat emaily. Prostě se zeptají přímo a hned, jak je to potřeba. Jen v takovém prostředí dokážete vytvořit plnohodnotný cross-functional, self-organised a high-performing tým.

Takže tohle by měl být váš cíl. Někdy je to snadné, stačí lidi přestěhovat v rámci budovy a oddělení, jindy musíte nejdříve investovat do předání zkušeností a znalostí. To nastává např. v případě, kdy máte historicky tým frontend developerů v Praze a backendisty v Brně, nebo třeba experty na systém A v Košicích a Systém B v Bratislavě. Potom je nasnadě vytvoření dočasného distribuovaného týmu. Takový tým je na více lokacích, ale primárním cílem je naučit se od sebe tolik, aby výhledově mohli udělat co-lokované cross-functional týmy na jednom místě. To může trvat třeba půl roku, nebo rok. Ale dlouhodobě to je vyčerpávající. Jak takový distribuovaný tým udělat funkční? To je v dnešní době internetu snadné. Nejúspěšnější je postavit do každé lokace velkou obrazovku, web kameru a celý den mít živou session tak, aby se všichni viděli a slyšeli. Je to asi to jediné, co opravdu funguje. Zároveň je dobré se pokusit naplánovat pravidelná setkání celého týmu, a to nejen na společnou Retrospektivu ale i nějakou zábavu. Klíčem úspěchu je z emailové adresy udělat člověka. Vytvořit vztah. Znát se a být týmem, který drží při sobě.

Druhým dočasným řešením je nedělat distribuované týmy, ale dočasně členy týmů relokovat, aby se naučili to, co potřebují znát pro vytvoření co-lokovaného týmu a předali si zkušenosti a znalosti. To se používá často při mergích nebo v prostředích mergům podobným, kdy část systému je řešena v Německu, část v USA a část v Indii a vzhledem k časovým zónám by spolupráce popsaná výše fungovala jen těžko. Členové týmu se na několik týdnů stanou součástí jiného týmu, a když se zaučí, vrátí se zpět a postaví cross-functional tým na jednom místě.

Samozřejmě existují i výjimečné týmy, které měly na různých kontinentech po jednom členovi týmu a i tak fungovaly výborně. I tak můžete uspět. Je to jen o vás. Ti, o kterých vím, že v takovémto prostředí uspěli, se domluvili, že budou mít flexibilní pracovní dobu. Někdy budou pracovat brzo ráno, někdy začnou odpoledne, jindy ráno, v poledne si vezmou volno a pak zase večer. Tak, jak to tým zrovna potřebuje a oni můžou. Druhou částí dohody bylo, že kdykoliv pracují mají sluchátka a mikrofon a běžící audio session, aby spolu mohli v reálném čase mluvit.

Že se vám to nezdá snadné? Není. Proto Scrum doporučuje co-lokované týmy. A když už trváte na distribuovanosti, tady je pár tipů, které distribuovanost ve velkých korporacích pomohly úspěšně zvládnout. Rozhodnutí, jestli chcete být úspěšní v dnešním měnícím se světě je na vás. Svět ale nepočká. Když se do toho dáte dneska, možná to bude bolet, ale za rok z vás bude úplně jiná firma s daleko širšími možnostmi jak dosáhnout cíle a úspěchu 🙂

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

Jak naplánovat Sprint bez odhadů?

Jeden z nejčastějších nešvarů Scrum implementací je odhadování tásků v hodinách a jejich následné poměřování vůči kapacitě týmu. Je to krásná myšlenka, ale v praxi je to nesmysl, který trvá zbytečně dlouho a nic nepřináší. Snad jen to, že můžete nakreslit další zbytečnost – Sprint Burndown.

Myšlenka vychází z nepochopení Scrumu. Je to pozůstatek tradičního myšlení Organizace 1.0 kde jsme věřili, že lidi alias zdroje jsou stejně jen líná banda individuí, kteří když je nebudeme hlídat, tak nic neudělají. Scrum dává práci mnohdy ztracený smysl a tak generuje daleko motivovanější lidi, kteří se sami zlepšují a vymýšlejí jak dělat věci lépe. A kteří toho udělají víc i bez mikromanagementu a detailního vykazování.

Když tedy přestaneme odhadovat kvůli kontrole lidí v týmu, zbývá se podívat, jestli mohou být takhle detailní odhady přínosné týmu samotnému. Podívejme se nejprve na reálnou přesnost takových odhadů. V podstatě, každý odhad je jen jakási předpověď. Slovní spojení ‘přesný odhad‘ je oxymoron. Nemůže nastat. Proto také ve Scrumu neodhadujeme, kdy bude jedna konkrétní věc hotová, ale kolik Product Backlog Items se nám vejde do Sprintu. Nečekané vlivy, které se týmu za Sprint stanou, se tím zprůměrují. Každá individuální story může být výrazně jiná, než jsme čekali, ale v globálu to vyjde. Jedna bude náročnější, jiná snazší, někde se zasekneme, jinde to půjde lépe, než jsme čekali a obavy se nenaplní. Jediné, co je pro plánování Sprintu potřeba, je dobré porozumění Backlogu a jednotlivým Stories. Nikdy bychom neměli do Sprintu plánovat věci, kterým nerozumíme – ale v takovém případě ani pokus o odhady tásků nepomůže.

Praktika, která týmům pomůže porozumět položkám Backlogu a na základě toho je naplánovat do Sprintu je rozpadnout Stories na tásky/aktivity, o kterých věří, že je dokáží dokončit za maximálně den (tedy od Standupu do Standupu). Některé takové tásky budou trvat třeba i tři, čtyři dny, jiné tým dokončí za pár hodin. Není důležité zkoumat tyto výjimky, ty se stanou, ať budete dělat, co budete dělat. A jestli to nejsou výjimky a všechny tásky se ukázaly být příliš malé nebo příliš velké, příští Sprint to napravte tak, aby byly v průměru dokončitelné za den. Je to zdánlivě to samé, také odhadujeme, ale je ohromný rozdíl, jestli na takovou tásku napíšete 8h a nebo se jen každý Standup z odstupu podíváte na vaší Scrum tabuli a zhodnotíte celková posun týmu. Není třeba nic počítat. Scrum je empirický proces, koriguje se sám. Někde začněte a uvidíte. Obecně je nejlepším odhadem včerejší počasí. Stačí naplánovat tolik položek Backlogu, kolik jste dokončili minule. Co se tásků týče, když vám rozpadlé aktivity vyjdou na tak cca na polovinu dní, bude to tak akorát. Obvykle se totiž některé tásky v průběhu rozpadnou na menší kousky a jiné vzniknou. To je zcela normální, neboť řešení vniká teprve v průběhu Sprintu. Zkuste to a uvidíte, jak to půjde. Příští Sprint můžete cokoli změnit tak, abyste našli správný balanc a rytmus.

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.