Scrum | Zuzi's Blog o Agilu a Scrumu

Scrum jen naoko

Jak se pozná opravdový Scrum od toho co je implementovaný jen naoko? Tak úplně první co slyšíte je výraz ‘ceremonie’. Řeknete si, no dobře, oni jen nevědí jak se to jmenuje, ale to nic neznamená. Jenže právě terminologie často poukazuje na hlubší nepochopení. V devadesáti procentech případů, když slyšíte termín ceremonie, tak jsou to zbytečné nesmyslné meetingy, které se dělají jen proto, že je někdo nakázal – ať už ScrumMaster nebo Scrum jako takový – tedy ve Scrumu to tak musí být. Ostatně když se podíváte na definici, dozvíte se něco o okázalém postupu podle předpisů. Takové ceremonie jsou nejen k ničemu, ale otravují prostředí, žerou energii a hlavně, vytváří obecnou nechuť ke Agilu, Scrumu a vůbec.

Když Scrum aplikujete správně, víte že to jsou eventy, tedy něco, co se děje, protože pro to existuje potřeba. Neříkáte tomu ani meetingy (ty jsou povětšinou nudné a nutné) ale je to takový happening. Mohli byste říct že je přeci jedno jak to nazýváte, a na jednu stranu je, ale na druhou název vždy ukazuje část vnímání. Dejte eventům smysl, najděte znovu jejich hodnotu a nikdo si na ně nebude stěžovat.

K tomu je ale několik pre-requisit. Za prvé, Scrum není proces jak micromanagovat (ani řídit) jednotlivce. Je postavený na spolupráci cross-functional týmu. A to bohužel ve většině organizací kde mají ceremonie chybí. Tedy abych byla specifická, když se na ně podíváte blíž, nejsou tým, tedy nespolupracují, nejsou cross-functional, tedy nedodávají hodnotu, jednotlivci pracují každý na svém úkolu, a mají rozdělené role. Narazíte tak na frontendisty, backenddisty, experty na systém X, na který nikdo jiný nesmí sáhnout (rozuměj máme to v kontraktu), a také na spoustu dependencí. A také na velice složitý proces v Jiře, a občas i několikastránkový diagram, kdo co dělá. Ne, opravdu Scrum není proces na zpracovávání ticketů. Ale to by vyžadovalo razantní změnu myšlení.

Klíčem opravdového Scrumu je tým, který v krátkých iteracích dodává hodnotu zákazníkům, získává zpětnou vazbu pomocí které se mění a iteruje produkt a své fungování. Scrum neoptimalizuje na rychlost, ale na řešení komplexních problémů, kde možností je mnoho a dopředu úplně přesně nevíme jaký směr zvolit. Je flexibilní ke změnám a dokáže se rychle adaptovat.

Takže jak od takového technického Scrumu naoko k tomu opravdovému?

Definujte business hodnotu: Jakou máme vizi, čeho chceme dosáhnout a pro koho?
Najděte Product Ownera, který rozumí businessu, hodnotu vnímá, a je schopen se rozhodnout co uděláme teď, a zbytek později, nebo nikdy. Tomu dejte zodpovědnost za úspěch – tedy nejen dodávku ale i návratnost (ROI) produktu.
Postavte malé týmy, které dokáží hodnotu dodat end to end. Dejte jim autonomii se rozhodnout jak budou spolupracovat.
Dejte jim ScrumMastera (coache, ne projektového managera) aby jim pomáhal hledat lepší cesty fungování.

A to je vlastně všechno. Není to složité, ale spousta organizací se takové změně brání. Agile přináší velkou změnu fungování. A taková změna je vždy těžká.

Virtuální svět a Agile

Svět se změnil. Může se nám to líbit nebo nemusí, ale v principu nám asi nezbude nic jiného než se té změně přizpůsobit. Spousta firem dneska mluví o tom, že se nebude vracet do kanceláří a nechá z větší či menší části virtuální fungování. A spoustě zaměstnanců se zpět do kanceláří ani nechce. Může tedy agilní tým fungovat ve virtuálním světě? No tak co by nemohl. Virtuálních týmu fungovala spousta i dříve, takže tomu vlastně vůbec nic nebrání. To jediné co je virtuálním světě horší, je udržovat dobré vztahy mezi lidmi. Spolupráce totiž nevzniká jenom tím, že někomu řekneme, že jsou tým, nebo že jim dáme nástroje, aby mohli spolupracovat. Je to hodně o důvěře mezi lidmi, je to o schopnosti komunikovat, být ochotni otevřeně řešit konflikty. A to se na dálku nedělá úplně dobře. Samozřejmě nástroje jako Zoom, kde se vidíte navzájem a můžete spolu mluvit jako byste seděli v jedné kanceláři, můžete se přesunout s libovolnou diskuzí do vedlejšího virtuálního prostoru stejně jako jste to dělali, když jste byli v officu, spolupráci pomáhají. Problém je, že čím déle budou týmy fungovat pouze ve virtuálním prostoru, tím méně se budou znát a to nemluvím jenom o těch, co nastoupili již za virtuálního světa, ale funguje tam takzvané sejde z očí, sejde z mysli. Přestanou chodit spolu na oběd, nezajdou občas na pivo, nebudou mít prostor si jen tak popovídat jako kolegové. A tak jak půjde čas, bude stále těžší a těžší otevírat složitá témata, řešit konflikty a říkat si věci tak jak jsou. Můžete namítnout, že ve virtuálním světě si můžete dát spolu kafe, drink, oběd. Ale asi budete souhlasit s tím, že to není ono. V podstatě by se dalo říct, že dnešní virtuální týmy jedou na dluh. A dříve či později je to doběhne. A to nemluvíme o tom, že by to nešlo. Šlo. Ale znamenalo by to proaktivně vztahy budovat.

Stejně jako v klasickém světě, i ve virtuálním světě máte v podstatě na výběr dvě možnosti. Buď pracovat jako jednotlivci, kteří si v nějaké podobě rozdají, nebo dostanou úkoly a pak na nich samostatně pracují. To ale nemá s týmovou spoluprací nic společného a je to čistě práce jednotlivců. Druhou možností je postavit dobře fungující silný tým, ale takový tým aby fungoval spolu, musí aktivně a intenzivně spolupracovat. Takové týmy měly často postavenou online session třeba na Zoomu nebo Google Hangoutu, kde spolupracovali v rámci celého dne, mluvili spolu, řešili věci dohromady, povídali si. A viděli se. A budovali tak vzájemnou důvěru, porozumění a vazby. Dnešní týmy často vizuál podceňují, říkají my si zavoláme, my si napíšeme, pošleme si message po Slacku. A nemám nic proti Slacku, nic proti telefonu, nic proti emailu. Všechno jsou to dobré nástroje pro komunikaci, ale spolupráci nenahradí.

Takže jak taková spolupráce ve virtuálním světě vypadá? Ráno když takzvaně přijdete do práce se připojíte na online video call (Zoom, Google Hangout, … ) který běží celý den, takže to není žádný status meeting a začnete pracovat. S tím jak se začnou připojovat kolegové, je to jako kdyby chodili do práce a vstupovali do kanceláře. Řeknete si ahoj, popovídáte si, zeptáte se co je nového a začnete postupně pracovat. Během dne spolu mluvíte a pomáháte si. Dnešní nástroje standardně umožňují spolupráci více lidí na jedné věci, takže to není problém. Místo tabule na stěně a papírových lístečků můžete používat třeba Mural, Miro, nebo Google Jambord. Jako doplněk můžete použít Slack pro asynchronní komunikaci, ale hlavním komunikačním nástrojem je vždy již zmíněná videokonference.

Většina týmů ale narazí na to, že nemá dostatečně silnou motivací pro spolupráci, připadá jim, že vlastně spolupracovat nepotřebují. Že stačí, když pracují jako jednotlivci a jednou denně se syncnou. A tak často upřednostní vlastní pohodlí, tedy zůstat doma a na žádný call se nepřipojovat, před intenzivní spoluprací a komunikací s kolegy. Důvody pro to můžou být dva. Jedním z nich je již zmíněná pohodlnost a takový nezvyk být pořád na kameře, přeci jen je to pořád ještě nové. Druhým je pak většinou to, že nemají dostatečně silný společný cíl a tak jim připadá, že kolegy pro řešení svých vlastních úloh vlastně ani nepotřebují. A jsme zpět v individuální práci. Zdání ale často klame. Problémy, které většina firem v dnešní době řeší jsou komplexní a s komplexitou si poradí lépe týmy, než samostatně pracující jednotlivci. Když ono ale postavit dobře fungující tým je práce, která trvá a stojí spousty energie. Jako vždy máte samozřejmě na výběr pracovat jako jednotlivci, nebo investovat do formování týmu a využít jeho výhody. Něco mezi většinou nefunguje a bere si nevýhody z obojího a bohužel právě tam spousta týmů končí. Nevyvinou dostatečnou energii pro formování týmu, ale snaží se předstírat že tým jsou a nutí jednotlivce do týmových meetingů, které ale pro práci samostatně pracujících lidí nedávají smysl a přináší jen zbytečný overhead. Není to o meetingách, ale o silném společném cíli.

Na závěr, čím jednodušší nástroje, tím lepší. Nenechte se chytit do pasti nových nástrojů a nových funkcionalit a nepoužívejte pro každou příležitost něco jiného. Nikdy to nebylo o technologiích, ale o vztazích a důvěře mezi lidmi a otevřeností. Stejně jako vám v klasickém světě stačila zeď a pár barevných lístečků a to jak na Refinement, tak i Planning a Retrospektivou, tak vám ve virtuálním světě stačí jeden flexibilní board, třeba Mural. A víc nepotřebujete. V jednoduchosti je síla.

Pro inspiraci, tady jako bonus krátké video a post o virtuálním světě školení.

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.

Retrospektiva není pro stížnosti

Jednou z nejdůležitějších věcí, které Scrum zavádí do firem je Retrospektiva. Učí nás brát chyby a neúspěchy jako dobrou věc, tedy jako příležitost ke zlepšení. Co když se nám nepovede dobře se zorganizovat a nic na konci Sprintu nedodáme? Nevadí. Na konci Sprintu si dáme Retrospektivu, a zamyslíme se nad tím, co příště uděláme jinak, aby se nám to už nestalo. Co když toho tři Sprinty za sebou naplánujeme moc a pokaždé dodáme jen část? Dáme si Retrospektivu a zamyslíme se nad tím, jak změníme plánování Sprintů tak, aby odhad více odpovídal realitě. Některé věci jsou akutní a bolestivé a dostanou se na retrospektivu hned, jiným to chvíli trvá. Ale když se budou dít pravidelně, dříve či později je někdo bude považovat za tak otravné, že je zmíní. Retrospektiva ale není o tom si postěžovat a odejít, ale příležitost pro zlepšení. Proto každá Retrospektiva věnuje většinu času nikoliv stížnostem, co všechno nefunguje, ale hledání příčin proč se to děje a následně možností, co bychom s tím jako tým mohli udělat příští Sprint. Každá Retrospektiva proto musí končit alespoň jedním konkrétním krokem co tým udělá příští Sprint jinak, aby se daná oblast zlepšila. Nemusí se hned vyřešit, ale každé zlepšení se počítá. Obecně platí, že když máte takových akcí moc, často se tým rozptýlí a neudělá nic. Proto by takových akčních kroků nemělo být příliš. Vyberte si jen to nejdůležitější a s tím pohněte. Jednu dvě, maximálně tři akce. Příští retrospektivu si zase můžete vybrat něco jiného, nebo v tom stejném tématu pokračovat, podle důležitosti.

Kdyby vás retrospektiva zajímala, můžete si pustit mé video. Je starší, ale stále platné 🙂

ScrumMaster je Catalyst Leader

ScrumMaster je nejenom Servant Leader, ale také Catalyst Leader, který popisuje Bill Joiner ve své knize Leadership Agility. Catalyst Leader je třetím krokem na leadership cestě od Experta k Catalystovi. Expert je velmi jednoduše řečeno člověk, který má znalosti a zkušenosti na takové úrovni, že může ostatním radit a vést je svým příkladem. Expert ostatním umí věci vysvětlit a doporučit konkrétní postup. Achiever se zajímá hlavně o výsledek, je velmi soutěživý, má rád jasně definované cíle a věří, že dobrá výzva je nejlepším motivátorem. Achieveři berou lidi jako zdroje, které jim pomůžou dosáhnout svých cílů. Třetím stupněm je Catalyst. Catalyst Leader který chápe agile jako mindset, a jde v pochopení agilu hlouběji než jen do aplikace praktik, rolí a frameworků. Jejich klíčovým zaměřením je vytvoření prostředí, kde mohou být lidé úspěšní. Záleží jim na kultuře, kde vznikají vztahy mezi lidmi, zaměřují se na spolupráci, transparentnost a otevřenost. Umožňují lidem kolem sebe pracovat s týmy, nejen s jednotlivci. Jsou úspěšní ve komplexních situacích, hledají různé pohledy a rozmanitost, podporují inovativní a kreativní řešení.

2019-04-05-08-44-04-1-copy

ScrumMasteři musí Agilu věřit, být největšími nadšenci pro agilitu jako takovou široko daleko aby svým nadšením pro agilitu ‘zapálili’ i ostatní. Musí umět použít všech pět přístupů ScrumMaster State of Mind, umět věci dobře vysvětlit, vyprávět příběhy, analyzovat příčiny, koučovat nejen jednotlivce ale i týmy, facilitovat velké skupiny, a to zdaleka není všechno. Jejich znalosti musí jít nad rámec frameworků, praktik a metod. Potřebují zlepšit své leadership schopnosti, porozumět struktuře a kultuře organizací, business agilitě a být dobří v řízení změn, protože agilita je obrovská změna způsobu myšlení a přístupu k věcem.

Jako Expert Leader řídíte auto pouze na jednom rychlostním stupni – učení, vysvětlování, doporučení. Achiever Leadeři přidávají tlak, který v agilním světě není moc užitečný, pokud uvažujete o cíli ScrumMaster dosáhnout sebeorganizace. Být Catalyst Leader je tedy jediný způsob, jak se stát skvělým ScrumMasterem. ScrumMaster musí umět vytvářet prostředí ve kterých týmy rostou, přebírají za věci zodpovědnost a přichází sami s kreativními řešeními. Jen tak se stanou úspěšnými v komplexním VUCA světě.

Kanban nebo Scrum?

Já osobně mám ráda Scrum. Primárně proto, že je týmově orientovaný a pomáhá stavět dobře fungující samoorganizované týmy. Je to lehký framework, který nedefinuje detailní praktiky a je tak dobře aplikovatelný na různá prostředí. Scrum se hodí na problémy komplexního světa (VUCA), které jsou jen obtížně predikovatelné a řešení vyžaduje jistou dávku kreativního myšlení. Obecně se používá na problémy, kde potřebujete strategicky prioritizovat, jako jsou libovolné produkty.
Kanban tak jak ho známe filozoficky vzešel z prostředí tovární výroby a je vhodný na reaktivní prostředí, kde prioritizujeme za běhu podle aktuální důležitosti. Kanban má v podstatě tři pilíře: vizualizace, minimalizace rozpracované práce (Work in progress – WIP) a optimalizace času průchodu (Leade time). Vizualizace týmům pomáhá hledat zlepšení a optimalizovat flow tedy čas průchodu a WIP limit zvyšuje focus. Když Toyota implementovala Kanban, měla cíl mít ve výrobní lince jen jedno auto. Nemyslím, že se dostala až tak daleko, ale skladové zásoby významně omezila a čas průchodu výrazně zrychlila.
Abych se vrátila ke své úvodní větě, já osobně mám radši Scrum. Všechny tři Kanban principy jsou obsažené ve Scrumu, takže tyto dva přístupy nejsou nijak vzdálené. Vizualizace je ve Scrumu zajištěná transparentním Product Backlogem a Sprint Backlogem, k čemuž si týmy si většinou jako doplněk přidají i nějakou tabuli, minimalizace rozpracované práce je daná krátkými Sprinty a Sprint Backlogem, a optimalizace celého fungování a organizace práce probíhá v rámci pravidelných Retrospektiv. Scrum je sice na začátku zdánlivě komplikovanější na aplikaci (musíte mít nové role, eventy a artefakty) ale ty zároveň týmy změnou efektivně provedou a Scrum má tak daleko větší úspěšnost než Kanban, který toho moc nepředepisuje a nechává týmům velkou volnost nic neměnit a dělat věci postaru. Samozřejmě když agilní mindset máte, Kanban vám půjde snadno a určitě pomůže se zlepšit. Když ale k němu přistoupíte s klasickým přístupem, žádné zlepšení se obvykle nekoná a jediné co po Kanbanu zbyde jsou naprosto neužitečné tabule s lístečky, které nikdo nepoužívá, neupdatuje, a tedy žádná změna k lepšímu nenastane. Na závěr připomenu, že všechno můžete zkazit. Samozřejmě i Scrum. A že jsem nepovedených implementací viděla spoustu. Ale Kanban je k tomu o trochu víc náchylný.

Jaké to bylo napsat další knihu

V prosinci mi v USA vyšla další kniha – The Agile Leader: Leveraging the Power of Influence. Stejně jako Great ScrumMaster je to takový přehled toho, co by si měl agilní leader uvědomit a co by měl znát. Na český překlad si budete v této době asi muset chvíli počkat, ale třeba na něj časem také dojde. 🙂

Kniha Agile Leader přináší takové ‘tasting menu‘ relevantních konceptů ve světě agilních organizací. Kniha je vlastně takovým pokračováním Great ScrumMastera, kde se díváme na to, jak se během své agilní cesty mění organizace. Je určená pro manažery, ředitele, vedoucí pracovníky a podnikatele – prostě všechny, bez ohledu na pozici, kdo jsou připraveni převzít za změnu zodpovědnost a stát se leaderem. Je průvodcem pro všechny, kteří se chtějí stát pravým agilním leaderem.

“Ještě nikdy v historii lidstva neexistovala taková poptávka po agilních leaderech. Po leaderech, kteří když se vše mění vytvářejí klid v lidech kolem sebe. Leaderech, kteří čelí nestálosti a dvojznačnosti s důvěrou ve vlastní schopnosti a schopnosti svého týmu přizpůsobit se. A leaderech, kteří vidí a akceptují komplexitu systémů kolem nich.” – Evan Leybourn, Business Agility Institute

“O agilním leadershipu je toho v dnešní době hodně slyšet. Dobrou zprávou je, že organizace si dnes uvědomují, že agilitu potřebují. Zuzana Sochová ve své knize jasně a s příklady vysvětluje, jak by každý z nás mohl o agilním leadershipu přemýšlet. Pomáhá nám orientovat se v tom, jak fungují agilní organizace, jaká struktura a kultura podporují agilitu a jak se mění agilní leadership.“ – Johanna Rothman, autorka knihy „Modern Management Made Easy” a dalších knih

Knihu jsem psala asi rok a hodně jsem stavěla na zkušenostech z executive leadership coachingu a ze svého Leadership development programu (CAL – Certified Agile Leadership) kde pracuji z leadery z velkých i malých organizací v rámci jejich rozvoje. Je plná praktických tipů a cvičení, kde se můžete podívat nejen na to, kde na své osobní cestě jako agilní leadeři jste, ale i jak nasbírat inspiraci, jak by se mohla změnit vaše organizace. A aby to nebylo jen o mých zkušenostech, do knihy přispělo svými zkušenostmi mnoho zkušených agilistů a v rámci krátkých příběhů se s vámi podělili o své zkušenosti.

Stejně jako všechny moje ostatní knihy, hodně stojí na ilustracích. Těmi vždy začínám, když něco píšu. V momentě kdy jsem schopna hlavní myšlenky sumarizovat v rámci několika obrázků, jsem připravena psát. Když se na to tak dívám zpětně, napsat knihu je vždy spousta práce. Tedy napsat samotnou knihu je v pohodě, ale projít celým cyklem review, editorů, a změnou grafiky, to je teprve vyčerpávající proces. Vždycky si říkám, že další knihu už nenapíšu. Vlastně bych to v té fázi možná i vzdala, ale už je podepsaná smlouva a tak to nejde. Což je asi dobře. Bez ní bych našla tisíc výmluv 🙂

Kniha je v současnosti k dispozici na Amazonu, a to jak v papírové podobě tak i jako elektronická kniha. Více se o knize dočtete na stránkách knihy.

Doufám, že se vám kniha bude líbit a že vám na vaší agilní cestě bude prospěšná.

Experimenty a pocit bezpečí

Jedním ze základních pilířů Agilu je pocit bezpečí. Pocit, že můžete udělat chybu, že nehledáte perfektní řešení, ale jen něco, co je v danou chvíli dostatečně dobré. Pocit, že můžete věci zkoušet a dělat experimenty. A že když se vám to náhodou nepovede, tak se nic neděje. Dáte si Retrospektivu, a zamyslíte se co příště můžete udělat jinak, aby se vám to už nestalo. Je to jednoduchý koncept, kde za chybu nepřichází penalizace, ale berete ji jako dobrou věc. Pomohla vám se nějak zlepšit a něco se naučit. Vždycky když o tom mluvím, lidi kývou. A když přejdu k praktické implementaci a zeptám se jich, jestli jsou ochotni experimentovat a definuji experiment jako něco, kde z deseti experimentů se povede jeden, vidíte nakolik mají kulturu neomylnosti a perfekcionalismu zakódovanou v kultuře a mindsetu. Nakolik se bojí udělat i sebemenší chybu. Vede to pak ke kultuře alibismu, kde se schováváme za procesy a úkoly definované někým jiným, jen abychom nemuseli převzít zodpovědnost a někdo nemohl říct, že je to naše vina.

Experiments

Asi nemusím zdůrazňovat, že Agile nejen nutně vyžaduje pocit bezpečí jako prerequisitu, aby vůbec mohl fungovat, ale i experimenty, abychom mohli zkoušet nové věci a hledat řešení na komplexní problémy businessu a učit se ze zpětné vazby. Na triviální věci, na které znáte řešení je Agile zbytečně drahý. Agile se hodí na řešení komplexních problémů, kde je velmi nízká předvídatelnost a plány většinou failují. A taková je v současnosti povaha businessu většiny firem. Proto Agile nabírá na popularitě a principy agilu aplikují firmy napříč celým spektrem. Takže až se do agilu pustíte také vy, nezapomeňte, že bezpečné prostředí a experimenty jsou nedílnou součástí úspěšné agility. Umožní vám kreativity a inovativní přístup který je pro řešení komplexních problémů klíčový.

Nástroje

Pořád se někdo ptá, jaké nástroje má používat. A když řeknu, že o nástrojích to není, že důležitější je porozumět tomu, jak chceme pracovat, moc nadšení tím nezískám. Tak jsem si říkala, že zkusím tedy doporučit, jak začít. To, co pomohlo mně, tedy používat zdi jako pracovní plochy. V takové firmě to žije, zdi jsou pokreslené návrhy, plné lístečků, a lidi se kolem nich shlukují a diskutují. Nic jiného přeci pro práci ve Scrumu nepotřebujete. Když se jdu podívat do agilních firem, přesně tohle potkávám. Je to flexibilní, viditelné pořád a pro všechny. Žádné restrikce, žádná daná pravidla. Tým si sám určí, co a jak potřebuje vidět. Ale jak asi tušíte, ani s tímto doporučením nikdy moc nadšení nezískám. Musí přeci existovat agilní nástroj, že… v dnešní době používat papírové lístečky je přeci zastaralé… Možná zastaralé, ale funkční. Takhle třeba vypadá office Meno Innovations. Velice zajímavá agilní firma, kterou jsem měla příležitost loni v létě navštívit.

Collaboration space at Menlo Innovations

Nicméně svět se mění a jednu z mála užitečných věcí co nám rok 2020 přinesl, jsou virtuální plochy jako je Mural a Miro. Asi tady byly i dříve, ale klasické organizace je nehledaly, a ty agilní upřednostňovaly výše zmíněné zdi. Takže když už jste v té nepříjemné situaci, že máte virtuální tým a hledáte, jak byste jako tým mohli i ve virtuálním světě spolupracovat, doporučím vám Mural. Je jednodušší než Miro, a tak se ho lidi snáze naučí. Je flexibilní a můžete v něm dělat úplně cokoliv od Backlog Refinementu po Retrospektivu. A na závěr rada, nehledejte žádné složité šablony. V jednoduchosti je síla. Čím bližší to bude zdi s lístečky tím lépe. Kreativitě se meze nekladou.

Mural board collaboration

Z projekťáka ScrumMasterem

Spousta lidí si myslí, že Project Manageři jsou dobrými kandidáty na ScrumMastery. Ze zkušenosti tomu tak ale ne vždy je. Většina projekťáků má s přechodem na roli SrumMastera velké potíže. Je to hlavně o hodnotách a o tom, co považujete za důležité.

Asi největším rozdílem je, že ScrumMaster není zodpovědný za dodávku v rámci Sprintu, za kterou je zodpovědný Development tým, ani za dodávku produktu jako takového, za kterou je zodpovědný Product Owner, ale za to, aby tým dobře fungoval, zlepšoval se a byl takzvaně self-organized, tedy samoorganizovaný. A to vyžaduje úplně jiný přístup, než organizace práce na projektu. Je to o coachingu, facilitaci, nadšení a víře, že Agile a Scrum funguje a je tou správnou cestou, schopnosti měnit kulturu organizace a stavět dobře fungující týmy. Převážně jde o softskilly.

Dalším rozdílem je, že v agilním světě nejsou projekty. Ostatně není pro ně důvod. Dodávku řídíme pomocí Product backlogu, kde Product Owner položky backlogu prioritizuje, podle business value.

A posledním rozdílem je, že nám až tak nejde o efektivitu. Dodání více funkcionality zdaleka totiž neznamená že dodáte více hodnoty. Scrum je Business value-driven, customer-centric. Maximalizujeme hodnotu za minimalizace effortu. Estimaty, velocity a burndowny jsou jen pozůstatky tradičního světa, které mají jen pramálo společného s měřením dodané hodnoty.

Asi vidíte, že změna z projekťáka na ScrumMastera není zdaleka tak jednoduchá, jak se původně zdála. Není samozřejmě nemožná, ale spousta projekťáků si na ní vyláme zuby a zůstane ScrumMasterem z donucení. Jestli se chcete stát skvělým ScrumMasterem, moje rada je, zapomeňte, že jste kdy byli projekťáky a začněte úplně od nuly. Bude to tak snazší, než když budete neustále tyto světy porovnávat.