tým | 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.

Nový Scrum Guide

Minulý týden se objevila nová verze ScrumGuidu. A zdá se, že je to cesta dobrým směrem. Popis je srozumitelnější, jednodušší a obsahuje méně detailů. Tady je pár rozdílů.

Scrum Guide

#1 – Scrum Guide 2020 je jasnější

Scrum Guide 2020 je jednodušší a jasnější. Konečně je psán srozumitelným jazykem a jasně popisuje co je Scrum. A protože Scrum je jednoduchý, je příjemné vidět že Scrum Guide může být také jednoduchý. Konečně se dobře čte a konečně jsme se zbavili přílišných detailů, jakým byly tři otázky na Daily Scrumu. Po mnoha letech neporozumění, kdy týmy brali Daily Scrum jako meeting kde každý reportuje svůj status, doporučuje Scrum Guide týmům vybrat si jakoukoli formu která jim pomůže lépe spolupracovat a maximalizovat hodnotu vzhledem ke Sprint Goalu. Za mě naprosto super.

#2 – Vše je o mindsetu

Líbí se mi, že nový Scrum Guide vypichuje tři pilíře emiricismu (transparentnost, inspection, adaptation) jako důležitou součást Scrumu spolu s pěti hodnotami Scrumu – commitment, focus, otevřenost, respekt, a odvaha a že se upřednostňuje to jak se lidé chovají před procesy a praktikami.

Další dobrou věcí je připomenutí, že Scrum se hodí primárně pro řešení komplexních problémů v nepředvídatelných prostředích a že různé techniky odhadování, měření velocity a kreslení burndown grafů se sice může zdát na první pohled užitečné, ale ve Scrumu upřednostňujeme schopnost rychle se měnit na základě zpětné vazby, tedy empirický přístup.

#3 – Scrum Team Focus

Největší změnou je to, že Scrum tým netvoří “Development tým”, ScrumMaster a Product Owner, ale “Developers”, ScrumMaster, a Product Owner. Vypadá to zdánlivě jako velká změna, ale není tomu tak. V obou případech všichni spolupracovali na maximalizaci hodnoty vzhledem ke Sprint Goalu, takže se vlastně nic nemění, jen jsme se snad nadobro zbavili typického nepochopení Scrumu, kde tým dodával Product Ownerovi a bral ho jako nepřítele. Teď je explicitně řečeno, že jsou na prvním místě týmem a že na výsledné hodnotě spolupracují. Tedy žádný dodavatel – odběratel vztah, ale cross-functional tým, co táhne za jeden provaz. Jsou v tom spolu.

Jediná vada na kráse je, že ‘Developer’ je dost nešťastně zvolené jméno, protože většině lidí asociuje software developera. Lepší výraz by asi byl ‘product worker’, tedy někdo, kdo na produktu pracuje a má potřebné znalosti a zkušenosti k tomu, aby týmu pomohl dodat end-to-end hodnotu pro zákazníka. Developeři jsou stále ti, kteří každý Sprint dodávají funkční produkt, zatímco Product Owner se zaměřuje na maximalizaci hodnoty a ScrumMaster na zlepšení fungování organizace a týmů.

Nový Scrum Guide přináší také jasnější doporučení pro scaling “Když by byl Scrum tým moc velký, můžete zvážit jeho rozdělení do více cross-functional Scrum týmů, které spolupracují na jednom produktu. V takovém případě týmy sdílí Product Goal, Product Backlog, a Product Ownera.”

#4 – Product Goal, Sprint Goal, a Increment

Konečně poslední změnou je přidání cíle produktu (Product Goal), lepší vysvětlení cíle Sprintu (Sprint Goal) a zjednodušení popisu Incrementu. Změny nejsou v praxi nové ale Scrum Guid zde dost pokulhával za běžnou praxí. Nový Scrum Guide nám take dává jistou definici produktu, která je mnohem širší, než si mnoho organizací myslí: “Produkt je nástrojem, který přináší hodnotu. Má jasnou hranici, známé stakeholdery, dobře definované uživatele nebo zákazníky. Produktem může být služba, fyzický produkt nebo něco abstraktnějšího.“ Product Goal je pro Scrum tým dlouhodobým cílem a vizí. Sprint Goal dává každému sprintu smysl a definuje hodnotu, na kterou se nyní zaměřujeme. Increment je funkční produkt který je kvalitně zpracován, otestován přináší hodnotu vzhledem ke Sprint Goalu. Jednoduché a jasné. Konečně také existuje mnohem lepší popis Definition of Done: „V okamžiku, kdy Product Backlog Item splňuje Definition of Done, zrodí se Increment.“

Celkově se mi nová verze Scrum Guidu opravdu líbí. Na tom, co jsem učila a používala, se nic moc nemění, přináší ale jasnější a čistší definici Scrumu, tak jak ho znám. A to je určitě dobře.

Agile jako sněhová koule

Spousta lidí si stěžuje, že oni nemůžou organizaci změnit, že to musí někdo shora. Nějaký manager. A čekají, až někdo vydá povel, příkaz, nebo změní procesy. Ale to se často neděje, a i když něco takového vznikne, jen málokdy jsou takové změny užitečné, protože managerům obecně chybí s čímkoliv agilním zkušenost. A tak si zase stěžujeme, a chceme, aby to někdo napravil, že jinak nemůžeme být ScrumMastery, Product Ownery, aplikovat Scrum, ani být agilní. Je to taková hra na schovávanou. Já bych se změnil, kdyby…

Za mě agilní transformace musí začínat u týmů. A to jak softwarových, businessových, tak i týmů executivců a po nějakém čase samozřejmě i boardu. Aby si všichni získali vlastní zkušenost s tím, jak se liší skupina jednotlivců od týmu. V kostce tým spolupracuje, důvěřuje si, jeho členové si do očí říkají i věci, kde spolu nesouhlasí, přebírají za věci vlastnictví a zodpovědnost, mají jeden společný cíl, za kterým jdou, nesoutěží navzájem mezi sebou. V podstatě je to snadné. V jednom týmu zkusíte Scrum, v jiném Kanban, v dalším třeba jen pár agilních praktik. Berete to jako experiment, který nemusí napoprvé vyjít a který pomocí rychlé zpětné vazby na retrospektivách upravujete tak, aby fungoval. A jak začíná fungovat, lidem se to líbí, úspěch se roznese a agilita se vám nabaluje jako sněhová koule. Vznikají další a další týmy, zajímají se o to další a další lidé. A zkouší si své vlastní experimenty.

Agile Journey

Když získáte dostatečnou zkušenost na úrovni jednotlivých týmů, jste ready na to začít experimentovat s agilitou na větších produktech kde vzájemně spolupracuje více týmů. Učíte se tak stavět sítě a spolupracující ekosystémy, které fungují na bázi samoorganizace, s vyšším stupněm autonomie a empowermentu. A stejně jako v předchozím kroku, je to o experimentování a pochopení agilního mindsetu a vytvoření jiné kultury.

Poslední krok je aplikace agilních principů na úroveň organizace. Je to chvíle, kdy mluvíme o Agile HR, Agile finance, Agile budgetting, Agile marketing, Agile Sales, Agile Leadership a vlastně obecně Agile mimo IT, business agility. Je to o kultuře, uvědomění si jaké máme hodnoty, a co to pro nás znamená je aplikovat do prostředí každodenních činností.

Manageři se často ptají, kdo řídí Agilní transformaci. Odpověď je většinou překvapí, protože agilní transformaci mají řídit ScrumMasteři. Ale my jsme mysleli, že to dostane na starosti nějaký manager… To se nevylučuje, ale aby to mohl dělat, musí se stát ScrumMasterem. Cílem ScrumMastera je umět tvořit self-organized týmy, komunity a systémy. ScrumMasteři jsou ti, kteří mění kulturu organizace a všeobecný mindset. Agile není o procesech, praktikách ani hierarchii, ale o jiném způsobu myšlení. A právě proto jsou ScrumMasteři ti praví, kteří by takovou změnou měli organizaci provázet. Tak ať se vám to daří.

Jestli vás téma agilních organizací a leadershipu zajímá, přijďte se o tématu dozvědět více na Certified Agile Leadership kurzu.

Agile jako změna

Změna není zas tak složitá, jak by se mohla zdát. V podstatě stačí jen začít. Začít dělat věci jinak. Být agilní. Co na tom je, že. Problém je, že bez toho, aniž byste změně věřili, nestane se. A věřit jí často začnete až když s novým způsobem fungování získáte dobrou zkušenost. Je to typický problém toho, co bylo dřív, slepice nebo vejce. Jak máme Agilu věřit, když jsme ho nikde nezažili. A jak ho máme zažít, když bez toho, abychom mu věřili to nikdo nezkusí. Existuje z toho několik cest. První, najít firmu ve které Agile funguje a získat tam zkušenosti, které pak dokážete aplikovat kdekoli jinde, protože už budete vědět, jak takový Agile má fungovat. Problém je, že v takové firmě se často nenaučíte jak organizace a jejich kulturu měnit. Takže pak často v klasickém prostředí narazíte. Druhý pohled je podívat se na teorii o change managementu, protože ve finále Agile je o změně fungování, mindsetu a kultury. Takže jak každou změnu začít? Guru change managementu John Kotter ve svých osmi krocích k úspěšné změně říká, že každá změna musí začít tím, že vytvoříte pocit urgence, nutnosti změny. Proč už nemůžeme věci dělat tak, jako všechny ty roky doteď? Co se stane, když se nezměníme a budeme v zaběhnutých kolejích pokračovat? A jestli takový pocit naléhavosti nedokážete v ostatních vzbudit, je vlastně úplně jedno, co je učíte a co jim vysvětlujete. Neudělají to a nezmění se. Budou pro to mít různé více či méně úsměvné důvody, ale dříve či později vás vytlačí pryč jako blázna, který jim nutí věci co nikdo k ničemu nepotřebuje. Agile nikdy neměl být váš cíl. Agile je jen cesta, jak některých vašich strategických cílů např. flexibilita, vyšší hodnota, kvalita, spokojenost zákazníků apod. dosáhnout. Vzpomeňte si na to, až se budete někde snažit změnit fungování týmu nebo organizace. Bez dostatečně silného důvodu pro změnu se žádná změna nestane. Proto by každá Agilní transformace měla začínat otázkou proč se vlastně vůbec chceme měnit. A dokud nevznikne pocit naléhavosti změny, vlastně nemá ani cenu se změnou začínat.

Flat organizace

Flat organizace, tedy organizace s plochou organizační strukturou, jsou často skloňované spolu s termínem agilní organizace a business agility. Lidé jim ale většinou nerozumí a ptají se, jak může organizace fungovat, když nemá managery, kteří rozhodují. Na bázi self-organizace. Samoorganizující se týmy jsou hlavní stavební jednotkou. Flat organizace jsou ale obvykle v tomto konceptu ještě o krok či dva dál a aplikují nejen koncept self-organized týmů (samostatně se rozhodují, jak budou pracovat na svých úlohách) ale i self-managed (samostatně řídí své procesy a kontrolují svůj progress), ale i self-designing (samostatně sestavují týmy v rámci organizace), nebo self-governing (samostatně nastavují směr). Jak už jsem zmínila několikrát, agilní organizace není jako tanker s centrálním rozhodováním a řízením. Je jako flotila malých lodiček s autonomním řízením, směřujících k jednomu cíli a smyslu existence organizace. Jsou dynamičtější v reakci na změnu a kreativnější a inovativnější v hledání řešení. Nejsou ovšem zdaleka rychlejší. Ale o rychlost v komplexním světě až tak nejde. Rychlost je dobrá ve světě, kde víte, co máte udělat, dokážete to naplánovat, a podle toho plánu dodat. Současná dynamika businessu velkým plánům moc nepřeje, a tak spousta firem, které se z ničeho nic ocitli v komplexním světě, který se mění tak rychle, že veškeré plány se velice rychle ukazují zastaralé a pomalé, experimentuje s agilem, který svým principem inspect and adapt reaguje na komplexní a nepředvídatelné VUCA prostředí daleko lépe než klasické metody řízení organizace.

Co tedy taková flat organizace potřebuje? Agilní mindset na úrovni organizace, kulturu postavenou na otevřenosti a spolupráci a takzvaný evolutionary purpose. Tedy cíl, který je spoluvlastněn a spoluvytvářen celou organizací, vizi, která spojuje a motivuje, smysl existence, kterému všichni věří a jsou ochotni mu něco obětovat. Tým se od skupiny jednotlivců liší tím, že si věří navzájem, dokáže si říct věci do očí tak jak jsou, převzít zodpovědnost, ale hlavně, že má jeden cíl, za kterým všichni jdou. S agilní flat organizací je to stejné, jen ve větším. Důvěra, otevřenost a respekt musí fungovat ve větším celku. Cíl, za kterým jdou musí být silnější, aby je dokázal spojit a dal jim energii překonat každodenní překážky. Nepotřebujete orgchart, nepotřebujete pozice, oddělení ani management. Potřebujete leadership, tedy ochotu lidí v organizaci se zapojit a dát do toho maximum.

Co tedy lidem nejvíce brání to zkusit? Asi za vším stojí nedostatek zkušeností, byť jen s malým self-organized týmem. Proto je to, co tu teď píšu, stále ještě pro většinu lidí nestravitelné. Když takovou zkušenost máte, je to obava že to, co fungovalo u pěti až sedmi lidí v týmu, nebude fungovat ve velkém. Tak se pojďme podívat. Co třeba Haier. Firma, která eliminovala dvanáct tisíc lidí ve středním managementu a vytvořila tisíce ‘micro-enterprises’ tedy minifirem, z nichž každá je zaměřená na dodání hodnoty konkrétním uživatelům. Zhang Ruimin na loňském Drucker foru říkal, že firmy, které se nedokážou přetransformovat na eco-systém, nepřežijí. A takových organizací jako Haier je spousta. Stačí jen zapojit Google, chtít je najít a být otevřeni inspiraci.

Proč Scrum ve firmách nefunguje

Čas od času přijde někdo a říká, že Scrum nefunguje a že oni jsou agilní a to že je lepší. Dovolím si oponovat. Ne proto, že by někdo nemohl být agilní bez Scrumu, ale proto, že teorie a realita jsou obvykle dost daleko od sebe a Scrum je zatím stále nejjednodušší a nejúspěšnější cesta, jak se stát agilními. Nemusíte souhlasit, ani pokračovat ve čtení. Ani jedno není povinné. Ale jestli vás zajímá můj názor na to, proč Scrum v některých prostředích nefunguje, tak tady je hned několik nejčastějších důvodů. Není to o businessu, ve kterém jste, ani o velikosti. Dobrá zpráva je, že všechny jsou snadno řešitelné, jak jinak než implementaci opravdového Scrumu, nikoliv fake-Scrumu, nebo “DarkScrumu“.

#1: Neexistence týmu

Nejčastějším důvodem, proč Scrum nefunguje je, že nemáte tým. Lidi pracují každý na svých úkolech, jako jednotlivci. V takovém případě se vytrácí celá podstata Scrumu a zbudou nesmyslná pravidla a “DarkScrum“ je temně černý. Tým je podstatou kvality, motivace, schopnosti adresovat komplexní problémy a nacházet inovativní řešení. Jak se tedy liší tým od skupiny jednotlivců? Tím že spolupracuje. Je postavený na důvěře, schopnosti nebát se říct si věci do očí, k něčemu se společně zavázat, vzít za věci zodpovědnost, a mít jeden společný cíl (viz kniha Five Dysfunctions of a Team). Začít můžete tak, že tým má jeden společný Sprint Goal (businessovou vizi sprintu), která je spojuje a společně plánuje, jak by v rámci Sprintu tuto hodnotu mohli maximalizovat (forecast). Když nechcete aplikovat rovnou mob-programming a pracovat všichni najednou na jednom úkolu, jednom počítači a jedné klávesnici, dobrou praktikou pro posílení spolupráce je “one story at a time“ kde celý tým spolupracuje na různých úkolech jedné konkrétní položky backlogu alias story a teprve když ji dokončí, dá se společně na další. Tým na to nepotřebuje žádného manažera ani asistenta, organizuje se sám. Dobrá zpráva je, že na to, abyste měli skvěle fungující self-organized tým je tady ScrumMaster.

#2: Komponent týmy

Kromě toho že je to self-organized tým, musí být také cross-functional. To neznamená že každý umí všechno, ale že jako tým mají všechny potřebné znalosti a zkušenosti k tomu, aby mohli vzít libovolnou položku backlogu a tu dokončit. Sami, bez dependencí na kohokoli jiného. Klasicky smýšlející organizace se často takové bojí týmy postavit. Většinou za tím stojí strach o ztrátu moci, nebo limitující kontrakty s dodavateli a obava je změnit. Firmy proto končí s komponentně orientovanými týmy, které i při nejlepší vůli nedokážou udělat nic, co by za něco stálo a dokázalo se prezentovat zákazníkům na Sprint Review, ze kterého se stává bezduchá akceptace dílčích kousků. Nic, na co by šla získat zpětná vazba. “DarkScrum“ je více či méně tmavě šedý, v závislosti na tom jak fragmentované jsou komponenty a ošklivé dependence. Stejně jako v minulém bodě, vysvětlovat důležitost a prosazovat cross-functional tým je na ScrumMasterovi.

#3: Nejasná business hodnota

Dalším bohužel docela častým problémem je to, že nikdo není schopen definovat business hodnotu. Divili byste se, kolik organizací není schopno definovat vizi. Je to frustrující, a obvykle to končí tím, že týmy říkají „dejte nám specifikaci, my to podle ní vyrobíme“. A “DarkScrum“ je černo-černý. Ve Scrumu totiž žádná detailní specifikace neexistuje. Máme jen vizi produktu, businessově orientovaný Sprint Goal a businessové položky backlogu, které nejsou zaměřené na implementaci, ale na business value. Implementace je velice flexibilní a je na týmu ji v rámci Sprintu vymyslet tak, aby se hodnota dodaná v daném Sprintu maximalizovala. To je ostatně rolí Product Ownera, který musí mít autoritu rozhodnout o prioritách, a být schopen upřednostnit tu část Backlogu, která přináší nejvyšší hodnotu.

#4: Proč bychom se měli měnit?

Asi posledním z důvodů, proč vám Scrum nefunguje, ale kterým byste asi měli začít, je uvědomit si proč byste se měli měnit. Co se stane, když se nezměníte. Že nebudete agilní? No to asi nikomu nevadí. Agile není váš cíl, ale jen cesta, jak se k němu dostat. A Scrum není jediná možnost jak se agilními stát. Jen podle mne ta nejefektivnější a nejúspěšnější. Jak říká guru change managementu John Kotter, když chcete, aby změna byla úspěšná, musíte vytvořit pocit nutnosti, neodkladnosti, urgentnosti. Lidi ani organizace se nemění, protože někdo vymyslel nový proces. Mění se, protože musí. Není to o tom, jestli se vám současný proces líbí nebo ne, pomáhala jsem změnit se firmám, které milovaly waterfall. Ale jediné firmě, které pomoct neumím je té, co nechce. Bez pocitu, že změnu nutně potřebují se žádná změna nestane. Je to moc práce. A změna kultury a mindsetu, kterou Agile a Scrum přináší je ta nejtěžší, kterou znám. Jestli se tedy chcete už v začátku vyvarovat stupňům šedi “DarkScrumu“, začněte s jasným důvodem, proč je změna nutná. Celá implementace bude pak výrazně méně náchylná k “tmavnutí“. Je to jako posílení imunity, jako vitamíny.

#5: Částečný Scrum

Jestliže předchozí odstavce jsou dané nepochopením, tohle je čistý alibizmus. Není to důvod proč Scrum nefunguje. Není to totiž Scrum. V angličtině se tomu říká Scrum-but. Tedy “my máme Scrum, ale neděláme retrospektivy. My máme Scrum, ale nemáme ScrumMastera, my máme Scrum, ale nemáme cross-functional týmy“. Nikdo vás nenutí Scrum nasadit, ale když už se do toho pustíte, tak buď pořádně, anebo vůbec. To, že nějaký paskvil nazvete Scrumem nepomůže ani vám, ani ostatním. Ba právě naopak. Ostatní odradí od toho to zkusit pořádně a vám přinese jen tu nejčernější verzi “DarkScrumu“.

Agile HR: Úvaha o platech a pozicích

Abych odpověděla na jeden dotaz, co přišel z LinkedIn v návaznosti na předchozí článek. Platy a pozice spolu ve firmě postavené na cross-týmové spolupráci nemají nic společného.

Pozice obecně nejsou potřeba, protože všichni jsou součástí nějakého týmu, jak jde čas, týmy se v závislosti na iniciativách a prioritách mění, a leaderem iniciativy se dynamicky stává ten, kdo se pro danou iniciativu nejvíce hodí. Proto nemluvíme o managementu, který je většinou daný fixně pozicí, ale leadershipu, který je o přístupu. Leaderem může být každý. Je to jen na vás a tom, jestli do toho chcete dát nadšení, energii a zodpovědnost.

Obecně nutnou podmínkou, aby vám to fungovalo, je porozumění a existence nějakého vyššího smyslu existence firmy (tzv. evolutionary purpose), abychom věděli, kam směřujeme a které iniciativy vizi firmy podporují a transparentní kultura založená na spolupráci a samoorganizaci.

Platy pak odpovídají více výsledkům než zásluhám z minulých let, či odsezené pozici. Jen tak pro zajímavost, v USA se teď začíná měnit struktura platů. Když děláte stejnou práci – třeba pracujete ve stejném týmu – máte mít stejný plat, bez ohledu na věk… Samozřejmě, když dokážete transparentně obhájit, že váš přínos je větší než ostatních, tak nikdo větší plat rozporovat nebude. Je to taková menší revoluce :), která nemá s Agilem nic společného, ale snaží se zamezit nižšímu ohodnocovaní žen. Ale filosoficky to dává v agilním světě smysl. V rychle měnícím se světě se buď udržíte mentálně na špičce, a pak nikdo vyšší plat nerozporuje, anebo vás ti, co právě vyšli ze školy strčí do rukávu, a pak není k vyššímu platu žádný důvod.

Chce to jistou sebedůvěru. Spousta zaměstnanců si zvykla na svá teplá místa, kde vlastně nemusí moc nic dělat ani nikomu nic dokazovat a plat běží a pozice se automaticky co dva tři roky zvedne a s ní další plat. Zkuste si chvíli představit, že zaměstnanci nejste a každý den musíte obhájit to, že vaše práce přináší firmě hodnotu. Ať už business hodnotu, investice do lidí okolo vás, nebo přímo peníze.

Jak začít? Máte dvě možnosti. První: půjdete tvrdou cestou – všem nabídnete dvě možnosti. Zůstanu ve firmě, protože věřím, že to má smysl, myslím, že mě to bude mě to bavit, a že mám znalosti a zkušenosti, které firma potřebuje (k tomu je třeba mít silný smysl a vizi organizace – tzv. evolutionary purpose) a věřím, že mě za to firma férově ohodnotí. To je typický startup mindset. Anebo vezmu balíček x platů a půjdu jinam.

Druhá cesta je inkrementální a pozvolná. Nejdříve musíte odpojit platy od pozic a pozice pomalounku polehounku přestat používat. Ostatně když se z nich trojčlenkou nepočítá plat, nikdo je ve firmě postavené na cross-functional týmech nepotřebuje. Tým spolupracuje a pozice se stávají zbytečné. Až se na ně zapomene, tak je odstraníte úplně. To, co vám bude chybět, je kvalitní peer-to-peer feedback. Ten ale s pozicemi nemá nic společného. Nicméně, až se ho jako firma naučíte, bude dobrým vstupem pro výše zmíněné platy.

Jestli musíte něco měnit? Nemusíte. Klidně si nechte to, co máte. Měňte jen věci, které změnu potřebují. Ale kdybyste se do toho chtěli pustit, třeba vám tato úvaha pomůže.

Agile HR: Jak hodnotíte zaměstnance?

A jako pokračování Agile HR série se pojďme podívat na hodnocení zaměstnanců, takzvaná performace reviews. V klasických organizacích, kdy manageři určovali, co zaměstnanci dělají, to bylo snadné: Zadám úkol, zkontroluji úkol. Navíc vzhledem k tomu, že svět se zase až tolik neměnil, stačilo plnění úkolů vyhodnocovat ročně. Z tohoto světa vychází klasická KPIs a roční bonusy. V agilní organizaci je ale vymyslet smysluplné roční KPIs docela oříšek, protože většina z takto definovaných cílů se v průběhu roku několikrát změní. Druhým problémem je menší fokus na jednotlivce ve prospěch týmu. To je druhá oblast, ve které klasická performance reviews selhávají.

Takže co s tím? První, obvykle poměrně snadná změna, je postavit cíle pro týmy, nikoli jednotlivce a tím je směřovat jako celek. Tým už se o své členy postará sám. Ostatně ne nadarmo jsme investovali spoustu energie z nich udělat agilní tým, kde si jednotliví členové věří, jsou otevření, přebírají zodpovědnost, který je jedním slovem self-organized. Scrum na formování takového týmu má speciální roli ScrumMastera. Takže na tom není nic složitého, stačí dělat pravidelné retrospektivy a pro okořenění můžete použít některé praktiky Management 3.0 například Kudo cards. Feedback od kolegů, kteří s vámi pracují je daleko efektivnější než feedback od managera, co toho o vašem fungování zas tak moc neví.

Jedna z oblíbených agilních praktik hodnocení v rámci týmu je založená na našem vztahu k penězům. Dejte každému určitou sumu s tím, že ji můžou jakkoli rozdělit členům týmu, ale nesmí si ji nechat. Tým získá okamžitou zpětnou vazbu o tom, jak si koho jednotliví členové váží, a koho přínos naopak nevidí. Nedostat nic je ostrá zpětná vazba, a tak tuto praktiku používejte až v týmech, o kterých si myslíte, že jsou v performingu. Když ji použijete na tým ve Formingu, nebo Stormingu, obvykle se nestačíte divit a výsledek se blíží katastrofě 🙂