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

Agilní a Scrum Transformace

Agilní transformace většinou není vůbec snadná. Agile je jednoduchá filosofie, která do našeho života vrací selský rozum. Scrum jako takový má jen pár pravidel, rolí a artefaktů. Ale to pravé, co dělá Scrum Scrumem, je skryto v pochopení mindsetu, který je jednoduchý když o něm čtete, ale zdaleka není snadný aplikovat. Proto doporučujeme pro start balíček Agilního Coachingu, kdy vás zkušený coach provede tím, co to je opravdový Scrum a ušetří vám spoustu energie a času, kdy se to budete snažit bez zkušenosti pochopit a aplikovat sami.

Technický Scrum

Proto firmy často začínají takzvaným ‘Technickým Scrumem‘. A hned v začátku upozorním, že Technický Scrum není Scrum. Jak ho poznáte? Poměrně snadno. Je to procesní implementace všeho, o čem se ve Scrum Guideu píše, často až dogmatická. Ale když dva dělají totéž, není to vždy totéž. Těmto implementacím totiž chybí mindset. A tak je to pouze zdánlivě správně, tedy můžeme si odškrtnout, že máme v kalendáři naplánované všechny meetingy, které Scrum definuje, requirementy přejmenujeme na Backlog a máme tři role, ale často je vykonávané stejně jako předchozí pozice. Předstíráme změnu, ale v hloubi duše se zuby nehty snažíme dělat vše jako doposud. Řeší se tu individuální zodpovědnost, efektivita, reporting, přesné odhady. Kreslí se burndowny a mikromanaguje se. Většinou to není nijak příjemný stav. Meetingy jsou zbytečnými dlouhotrvajícími statusy a Sprinty jen otravným přerušováním práce, která se stejně musí všechna udělat. Prostě ‘dělají‘ Scrum, protože to tak někdo rozhodl. Není to Scrum, ale v některých organizacích je to nutný první krok ke změně.

Scrum Mindset

Když to nevzdáte, po čase přijdete na to, že pravý Scrum je o spolupráci a self-organizaci a začnou vám fungovat týmy, které se samy zlepšují a hledají lepší cestu, jak dodat hodnotu. Bude to kreativní a inovativní prostředí, kde nebudete jen ‘dělat‘ Scrum ale ‘žít‘ Scrum. Scrum se stane vaší nedílnou součástí, přejde vám do morku kostí a stane se součástí vaší DNA. První krok je obvykle ‘Týmový Scrum‘, kde se vám podaří postavit tým spolupracujících lidí, co mají jeden společný cíl. Je to kousek organizace, který přitahuje pozornost. Je lepší než jiné části, má větší energii. Vystupuje z běžného průměru. Často působí takovou silou, že nabaluje ostatní části. Týmy, které zkouší být taky takové, produkty které udělají ze zákazníka centrální bod a místo optimalizace rychlosti práce jednotlivců na technických úlohách začínáme optimalizovat dodanou business hodnotu. V momentě, kdy se na tento styl práce nabalí kritické množství týmů a produktů, vzniká takzvaný ‘Organizational Scrum‘ a mění se to, jak celá firma funguje, počínaje portfolio managementem, prioritizací, zapojením zákazníka, a konče prací s lidmi.

Abyste uspěli, potřebujete jen dvě věci. Dostatečný důvod se změnit a kuráž. Obojí je těžší, než se zdá, ale z mé zkušenosti výsledek rozhodně stojí za to.

Scrum Transformation

Agilní Leadership

Kdysi dávno jsem se snažila přijít na to, co říct leaderům klasických organizací, aby pochopili, o čem je vlastně Agile a Scrum, a co to pro ně znamená. Jak se mají změnit, co mají a nemají dělat. O trochu později jsem pochopila, že to celé byla úplně špatná otázka 🙂 No, lidi se učí a já taky. Někde tady vznikl koncept Agilního Leadership programu, který dnes úspěšně pomáhá firmám stát se moderními, nebo chcete-li opravdu Agilními.

S tím jak se mění organizace na flexibilnější, reagující na změny komplexního světa, Agilnější, přichází ruku v ruce i změna toho, jak takové firmy řídit. Jako součást svých kurzů pro leadery v Agilních organizacích jsem nakreslila tento model, pomocí kterého provádíme executive leadery, managery, ředitele, vlastníky firem změnou na Agilní organizaci. Není to o žádném konkrétním procesu. Na to máte ve firmách spoustu lidí, kteří je umí a implementují Agile, Scrum, Kanban, Extrem Programming, Lean, za vás. Je to o uvědomění si změny, porozumění a přijmutí nového stavu a schopnosti změnu aplikovat.

Agile Leadership

Agile Leadership model je založen na pochopení organizace jako systému. Organizace jako sytém je z podstaty věci komplexní. Neexistuje tu jasná vazba mezi příčinou a důsledkem. Je to síť vzájemně se ovlivňujících uzlů. Není předvídatelná, proto klasické metody řízení, které pochází z tradičního světa, selhávají. Očekávají totiž konzistentní predikovatelné chování. Takový byl svět někdy do roku 1970, než globalizace a internet zrychlili a zhustili svět natolik, že přestal být jen komplikovaný a vztah mezi příčinou a důsledkem se již nedá jednoznačně určit.

Complexity - Cinefin

Prvním bodem Agile Leadership modelu je Awareness – tedy uvědomění si reality, porozumění, informovanost. Organizace jako systém je nekonečným zdrojem signálů, které vám když budete pozorně sledovat, poslouchat a vnímat usnadní jeho pochopení. Druhým bodem je Embrace – tedy schopnost vstřebat realitu bez nutnosti ji hodnotit. Stát se její součástí se vším co to obnáší. Nakonec, je tu poslední bod, Change – schopnost ovlivnit jak se systém chová.

Tohle je ve zkratce Agilní leadership program. Žádná změna není zadarmo, a změna nás samotných je ta nejtěžší. Výsledek ale určitě stojí za to.

S tématem má i souvislost i můj článek Agilní organizace.

Od koho a jaká Scrum certifikace má opravdu hodnotu

Za autora Scrumu je považován Ken Schwaber a Jeff Sutherland. První veřejné školení Scrumu ale nakonec prý realizoval Ken Schwaber společně s Mikem Cohnem. Ono to možná nakonec není až tak důležité, kdo byl a nebyl první, důležité je, že všichni tito zakladatelé Scrumu a dnes vlastně Scrum legendy se v té době sdružili pod křídla Scrum Alliance, kterou založili v roce 2002 (zakladatelé byli Ken Schwaber, Mike Cohn a Esther Derby). Tím se vlastně Scrum Alliance stala první certifikační autoritou, která vydávala Scrum certifikace. Vznik certifikací nepřímo zapříčinila firma Xerox, která potřebovala své zaměstnance nejen proškolit ale i ocertifikovat – tak vzniklo CSM – Certified ScrumMaster.

Postupem času se cesty Kena a ostatních z původní Scrum komumity rozešly, Ken Schwaber si založil Scrum.org a Scrum Alliance pokračovala dál v započaté cestě. Obě tyto společnosti vydávají certifikace na Scrum proces, ale postupem času se jejich přístup k certifikacím diametrálně rozešel. Výsledkem je, že Scrum Alliance se drží původního myšlenky, jak certifikace udělovat a jak držet jejich kvalitu a vydává certifikace, které dnes mají na trhu opravdovou hodnotu. Díky tomu také jejich počet prudce roste a i pozice Scrum Alliance na světovém trhu. Je skvělé, že aktivní součástí Scrum Alliance je dodnes Jeff Sutherland, jeden ze spoluautorů Scrumu. Tím je zabezpečena kontinuita, aktuálnost, ale také kvalita. Ostatně podívejte se na poslední aktualizaci Scrum Guidu – je z roku 2016 a stojí za ním Jeff Sutherland (Scrum Alliance) a Ken Schwaber (Scrum.org).

Nikdo neříká, že nemůžete Scrum umět bez certifikace či certifikace je zlatý grál. Samozřejmě není. Ale pokud o certifikaci opravdu uvažujete, tak si dobře rozmyslete, od koho certifikace je. Díky popularitě Scrumu různá uskupení tvářící se jako certifikační autority tuší zisk snadných peněz – vždyť stačí test za pár dolarů a certifikace je vaše. Ale v tomto případě má tak cenu papíru, na kterém je vytištěna. Ostatně takový papír s nápisem Certifikace si můžete vyrobit i sami ve Wordu a bude mít úplně stejnou hodnotu. A je smutné, že do této skupiny se před lety přidal i Scrum.org, když umožnili certifikaci jen za test, čímž sami popřeli cestu, po které po založení šli a zcela opustili tlak na kvalitu a jméno certifikace. Když už ale do nějaké certifikace investujete, vždy je dobré mít certifikaci od někoho, kdo je pod Scrumem opravdu podepsaný, rozumí mu, a jehož certifikace má opravdu světově uznávanou platnost – a zde je aktuálně jen 1 možnost: certifikace od Scrum Alliance.

Scrum Alliance jako první certifikační autorita má díky své dlouhé historii celosvětově rozhodně větší impact a vlastnictví certifikace od Scrum Alliance je rozhodně výborná volba. Navíc v ČR a na Slovensku školení s certifikacemi od Scrum Alliance dlouhodobě a úspěšně pořádá několik společností a tyto certifikace jsou i na našem trhu velmi dobře známé a uznávané. Školení mohou vést pouze certifikovaní trenéři, kteří musí splnit opravdu náročné podmínky. Získání licence Certified Scrum Trainer není vůbec snadné a certifikační proces trvá rok a déle a zdaleka ne každý v něm uspěje. Díky tomu je laťka na kvalitu školení nastavena opravdu vysoko, čímž se drží i vysoký standard certifikací.

K získání je několik certifikací, ať nejoblíbenější CSM – Certified ScrumMaster, pro produkťáka CSPO – Certified Scrum Product Owner, či developerská CSD – Certified Scrum Developer či relativní novinka pro managery a leadery organizací CAL1 – Certified Agile Leadership I a následný program CAL2 – Certified Agile Leaderhip II. Jako další level je tu Advanced level, tj. A-CSM a A-CSPO po kterém následuje level professional CSP – Certified Scrum Professional kde držitelé musí prokázat praktickou zkušenost se Scrumem. I tento professional level se dnes dělí na dvě možnosti podle role, tj. CSP-SM a CSP-PO. A následně CTC – Certified Team Coach a CEC – Certified Entrprise Coach kteří spolu s CST – Certified Scrum Trainer jsou těmi pravými pomocníky s Agilní transformací.

Jinak pro představu ScrumAlliance je založená jako non-profit organizace, která se snaží investovat do Agilní a Scrum komunity. Pořádá pravidelně každý rok tři globální Scrum Gatheringy (Evropa, USA, Asie), a spoustu regionálních Gatheringů, coach campů, sponzoruje menší konference, podporuje lokální komunity. Mezi trenéry jsou opravdové legendy, ať už zmiňovaní Jeff Sutherland a JJ Sutherland, Mike Cohn, autoři LeSSu (Large Scale Scrum) Craig Larman a Bass Vodde, Maria Matarelli, která posouvá Agile a Scrum za hranice SW vývoje a zaměřuje se na Agilní marketing, Joe Justice, který je expert na Scrum v HW oblasti, Hendrik Kniberg známý ze Spotify, Roman Pichler, evropská legenda produktového vývoje, a tak bychom mohli pokračovat.

Pokud o certifikaci na Scrum uvažujete, dobře zvažte, jakou certifikaci si vyberete. Rozhodnutí je samozřejmě na vás, ale pokud mohu něco doporučit, vyhněte se tradičním certifikačním agenturám, které certifikují Waterfall – ti Scrumu nerozumí a jejich certifikace v Agilním světě nemá hodnotu. Vyhněte se různým Indickým agenturám s krásnou fotkou sídla v USA. Vyhněte se agenturám, které nabízí certifikaci za test. Agile = Mindset, a to se testem nedá ověřit. A lidé, co se v Agilním světě pohybují, to dobře vědí, a tak tyto certifikáty nemají větší hodnotu než již ten zmíněný kus papíru, co si ve Wordu napíšete sami. Přeji dobrý výběr.

Update: 2019.

Disclaimer: Jsem Certified Scrum Trainer od Scrum Alliance, takže můžete říct, že jsem „zaujatá“. Ale já opravdu věřím, že školeni s certifikacemi od Scrum Alliance vedené jejich certifikovanými trenéry jsou nejlepší a mají na trhu největší hodnotu. Proto neškolím certifikační Scrum školení pro jiná uskupení. Dostávala jsem na toto téma v poslední době opravdu hodně dotazů, doufám že na ně tento blog-post odpověděl.

Jak řešit chyby ve Scrumu?

Jedním z častých dotazů, které dostávám, je jak řešit ve Scrumu chyby. Je lepší mít separátní tým na chyby a separátní tým na nový development, nebo cross-functional týmy co pracují na tom, co je zrovna potřeba, tedy chybách i nových funkcionalitách. Odpověď je snadná. Scrum optimalizuje business value. Definuje proto týmy jako cross-functional, které dokáží udělat jakoukoli změnu produktu, co přináší business value. Tedy chceme tým (týmy) co pracují na tom, co je zrovna v produktu potřeba. Ať už je to chyba, nebo nová feature.

První, co je třeba si uvědomit je, že chyba je zase jen změna funkcionality, takže není sebemenší důvod, proč by chyby nemohly jít do Backlogu jako jakékoli jiné věci, které chcete ve vašem produktu změnit. Jsou to prostě obyčejné položky Backlogu, které by měl Product Owner prioritizovat podle business value. Když dám příklad, představte si, že máte hru, kde si hráči můžou nastavovat vlastní avatary. A jedním z možných nastavení je i barva vlasů. A co čert nechtěl, pokaždé když se odhlásíte, váš avatar barvu vlasů ztratí a je zase blond. Otrava, že? Jasná chyba, řekli byste. Takže ji musíme dát do Backlogu a opravit. Dokonce na to klidně můžete použít formát User Story a napsat:

Jako hráč,

chci, aby si můj avatar pamatoval barvu vlasů,

abych ji nemusel nastavovat pokaždé znova.

Když to uděláte, stane se zajímavá věc. Z něčeho co se musí opravit, se stane něco, co má business value (abych ji nemusel nastavovat pokaždé znova) a lze prioritizovat relativně vzhledem k ostatním položkám Product Backlogu. V tomto konkrétním případě nás to donutí zjistit, kolik hráčů tuto funkcionalitu s chybou kdy použilo, ale hlavně kolika z nich vadilo, že se přes noc stali blond. A když zjistíte, že existuje jediný hráč, kterému vadí, že nemá barevné vlasy, tak možná položka do Backlogu bude úplně jiná a bude naopak znamenat odstranění funkcionality jako takové.

Co když ale chyba není takhle nedůležitá, ale je kritická? Stojí vám produkce, uživatelé nemůžou produkt používat? No tak ji opravte. Že vám to narušuje Sprint? Je to výjimečná situace, a výjimky se dějí. Když celý tým onemocní, taky to berete jako výjimku a moc to neřešíte. Je třeba si uvědomit, na co klademe důraz. V tradičním světě waterfallu bylo hlavní chybu co nejrychleji opravit. Tím jsme problém považovali za vyřešený. V Agilním světě ji opravíme, a klidně i hned jestli je tak kritická, že nepočká do dalšího Sprintu. Pak si odpočineme, a zamyslíme se, co uděláme příště pro to, aby se nám to už nestalo. Najdeme rootcause, změníme své procesy, refactorujeme, prostě uděláme cokoli, aby se takovéhle kritické chyby neobjevovaly, a ty, které nám přeci jen utečou, jsme mohli v pohodě považovat za výjimky. Protože výjimečné věci se dějí výjimečně, moc nám nevadí. Dokážeme se z toho otřepat. Stejně jako když celý tým onemocní. Naopak obvyklé věci se dějí obvykle a mohou být pěkně vyčerpávající.

Knihu The Great ScrumMaster: #ScrumMasterWay vydalo nakladatelství Addison-Wesley

The Great ScrumMaster:#ScrumMasterWay

Začátkem roku 2016 jsme dopsala svoji další knihu The Great ScrumMaster: #ScrumMasterWay, kterou jsem si původně vydala sama jako elektronickou publikaci a distribuovala ji pomocí Amazonu ve verzi pro Kindle a následně si nechala vytisknout i papírovou limitovanou full-color edici v omezeném nákladu. Kniha se prodávala překvapivě hodně dobře a tak jsem si už byla vyzvednout pěkný šek od Amazonu v americkém Wells Fargu – dáte otisk palce a peníze jsou vaše 🙂 A dvakrát vyprodala limitovanou barevnou papírovou edici. Na rozdíl od první knihy Agilní metody řízení projektů (vydal Computer Press v roce 2014) jsem knihu tentokrát záměrně psala anglicky, protože mi přišlo téma výborného Scrum Mastera jako opomíjené a věřila jsem, že mé dlouholeté zkušenosti jsou aplikovatelné celosvětově, nejen u nás v ČR či na Slovensku, a kniha se prosadí. A měla jsem štěstí a tento názor se mnou sdílí i americké nakladatelství Addison-Wesley Professional (součást skupiny Pearson), které patří mezi jedno z největších světových nakladatelství technické literatury, a právě v těchto dnech moji knihu vydává. Mám z toho opravdu velkou radost, že kniha je pod křídly velkého a známého nakladatelství a bude dostupná na celosvětovém trhu.

Cesta k tomu cíli nebyla úplně snadná a opravdu velkou zásluhu na tom má Mike Cohn, jedna z legend Scrumu, kterého kniha nadchla a doporučil ji jako další publikaci do své série, které pro Addison-Wesley dělá editora. Takže má kniha je teď součástí série: Addison-Wesley Signature Series (Cohn) a jsem tím velmi poctěna. Když se podíváte na ostatní knihy v sérii, myslím, že jsem ve velmi dobré společnosti 🙂 Od doby doporučení Mika Cohna uběhlo mnoho času, kdy editoři pracovali na textu a grafici vylepšovali mé kreslené obrázky, než se dnes kniha objevila na trhu, ale o to větší z ní mám radost. Všichni udělali výbornou práci a já jsem ráda, že jsem mohla pracovat s takovým týmem profesionálů.

Zuzi Sochova & The Great ScrumMaster: #ScrumMasterWay bookJak již z názvu vyplývá, v knize se primárně věnujeme roli ScrumMastera. Kdo je dobrým ScrumMasterem, co by měl ideální ScrumMaster znát a umět, jak si představuji cestu ScrumMastera od prvních kroků až do excelentního stavu. Prostě jak se stát tím nejlepším ScrumMasterem na světě :). Nejedná se o žádnou suchou teorii, snažila jsem se udělat knihu hodně praktickou, vizuální, s hodně příklady, tak aby to bylo opravdu prakticky použitelné a realizovatelné v běžném životě.

Kniha čerpá z mých reálných zkušeností z mnoha týmů a firem, definuje nový koncept #ScrumMasterWay, který ukazuje ScrumMasterům cestu jak se stát skvělým ScrumMasterem.

Mně se o knize špatně píše, a tak vám radši rovnou doporučím si ji přečíst. Pokud by vás zajímaly další detaily, na stránce greatscrummaster.com se můžete dozvědět o knize více. Knihu je možné objednávat na Amazonu. Jestli se vám kniha bude líbit, prosím doporučte ji svým známým a kolegům anebo mi napište recenzi a pomozte mi tak knihu dostat do světa.

Doufám, že se vám bude kniha líbit.

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.

Agilní Organizace

Organizace se neustále vyvíjí. V době průmyslové revoluce se svět změnil k nepoznání. Z malých businessů začaly vznikat velké továrny. Bylo potřeba řídit velké množství dělníků a to dalo základy managementu, jak ho známe dnes.

Organization 1.0

organization 1.0Typickou strukturou byla hierarchická pyramida. Moc, motivace a směřování v podobě cukru a biče, pevná struktura a strmý žebříček pozic bylo v té době dobrou odpovědí na aktuální situaci.

Svět se změnil, a organizace se snažily řídit lidi stejně jako stroje. Definovaly fixní procesy, role, pravidla. Nebylo to nijak špatně, protože složitost většiny problémů na které organizace narážely, se daly vyřešit stanovením best practices. Obecně se mělo za to, že zaměstnanci jsou stejně jen líná banda flákačů a tak je potřeba pevný řád a kontrola. Většina lidí se pohybovala v tribal leadership levelu 2 “My life sucks“, tedy “Můj život je nanic“.

Organization 2.0

img_0752-300x225Jak šel čas, a prostředí businessu se stávalo složitější, firmy se měnily a hledaly cestu ve specializaci a rozdělení zodpovědností. Všechno se nejprve zanalyzovalo a pak teprve udělalo. Byla snaha složité problémy moderního světa rozsekat na jednoduché činnosti a ty pak řešit best practices na které jsme byli po léta zvyklí.

organization20

Organizace se předháněly v nových procesech a rolích. Stávaly se komplikovanějšími a neohrabanějšími. Hlavní motivací bylo stát se nejlepší na úkor ostatních. Majorita lidí se pohybuje v Tribal Leadersip level 3 “I‘m great, you are not“, tedy “Já jsem nejlepší, a vy ne“. Je to prostředí optimalizující jednotlivce. Jsou v něm manageři, kteří říkají, co mají ostatní dělat. Vzniká “Leader-Follower“ model. Od zaměstnanců se čeká, že se stanou promazanými kolečky složitého stroje.

Organization 3.0

Leader-follower V současnosti, kdy už svět není ani jednoduchý ani komplikovaný ale komplexní, je třeba umět na změny reagovat. Být dostatečně flexibilní, Agilní, chcete-li. Moderní organizace je uzpůsobená tak, aby neustále hledala a optimalizovala business hodnotu. Už není tak důležité, jak efektivně pracují jednotlivci. Podstatný je celkový výsledek a přínos. Komplexita moderního světa s sebou přinesla takovou složitost, že již není možné věci rozmyslet, popsat procesy, vytvořit zodpovědné role.

Agile organization 3.0Organizace potřebují tvořit adaptivní sítě, které jsou inovativní a kreativní a rychle reagují na změnu prostředí. Odpovědnost se z jednotlivce přenáší na týmy.
Současně s tím je třeba změnit leadership model z “Leader-Follower“ na “Leader-Leader“ kde týmy samy přebírají zodpovědnost a rozhodování v rámci firemní strategie do svých rukou a pomáhají organizaci stát se flexibilní.

Leader-Leader model

Tribal leadership model se postupně mění a většina lidí v takové organizaci jsou v levelu 4 “We are great“ tedy “My jsme nejlepší“. Firma již není tvořena nezávislými specialisty ale týmy, které dohromady tvoří systém. Systém, který je dynamický, flexibilní a dobře reaguje na komplexitu okolního světa. Je to jediná cesta, jak dlouhodobě uspět v současném komplexním světě. Moderní organizace jsou Agilní. Jsou tvořeny z lidí, kteří se vzájemně ovlivňují a spolu v rámci komplexního systému celé organizace reagují na okolní svět. Je to jiný svět, než na který jsme byli zvyklí. Ale je to jediná cesta jak reagovat na to co se děje kolem nás a být dlouhodobě úspěšní.

Agile Organization
Agile Organization

Jak začít?

– Organizace je tak dobrá, jak dobré má leadery. Upřednostňujte “Leader-Leader” leadership model a tvořte kulturu Tribal Leadership modelu “We are great!” tedy “My jsme nejlepší“.

– Decentralizujte, tvořte sítě and komunity. Umožněte autonomní rozhodování v rámci dobře definovaného prostoru.

– přečtěte si mojí knihu The Great ScrumMaster – #ScrumMasterWay která je dobrým průvodcem nejen pro ScrumMastery ale i leadery, managery a ředitele organizace která se chce stát Agilní Organizací 3.0.

Sprint Review

Sprint Review je jednoduchý meeting, který ale většina firem nepochopila. Jak se jako Agilní Coach chodím dívat na různé Scrum týmy, nejčastější chybou je, že Sprint Review považují za Sprint nebo Release status. A tak se tenhle zajímavý meeting stává pro spoustu firem noční můrou. Rozhoduje se zde, jestli byl tým úspěšný, kolik slíbil a kolik dodal. Ale to je zcela mimo definici toho, co by se tu mělo dít.

Jestli jste si oddychli, že takhle to u vás není, mám pro vás druhou nejčastější chybu, a to že na Sprint Review prezentuje tým Product Ownerovi co dokončil. Je to asi o chlup lepší, ale pořád úplně vedle. Product Owner je součást Scrum týmu a tedy dokončenou funkcionalitu akceptuje hned jak je hotová, tedy v průběhu Sprintu. Tedy na review už ji dávno viděl a dal na ni zpětnou vazbu.

Další chybou v pořadí je, že neprezentuje tým, ale Product Owner. Tým je přeci banda introvertů co nerozumí businessu, tak jak by mohli předstoupit před zákazníka, že? No alespoň oproti předchozím variantám něco ukazujete zákazníkovi a dostáváte zpětnou vazbu. O tu jde totiž na Sprint Review především.

Ideálním stavem je, že tým prezentuje zákazníkovi, co dokončil. A na oplátku získá zpětnou vazbu od zákazníka. Není to žádná technická prezentace jak je to naimplementované, ani přehlídka jednotlivých User Stories, ale souhrnná prezentace toho, jak jsme doručili za daný Sprint hodnotu definovanou cílem Sprintu.  Jak již jsem naznačila, prezentuje tým. Kdo konkrétně? No to je snadné, kdokoli. Z výborně fungujících týmů je schopný hodnotu Sprintu prezentovat kdokoli. Jak to vypadá v praxi? Přijdete na Sprint Review, tým vylosuje jednoho člena a ten prezentuje. Že to není možné? Když tým spolupracuje v rámci Sprintu vždy na jedné UserStory (viz praktika “One UserStory at a time“), není to problém. Je důležité si uvědomit, že neprezentujeme detailní řešení, ale Sprint Goal, tedy hodnotu dodanou v daném Sprintu.

Jak může vypadat Product Backlog – Příklad

Jak tak školím různé kurzy, spousta lidí se ptá, jestli mám někde příklad Product Backlogu. A já nikdy nevím jak jim vysvětlit, že je to snadné a nic složitého na tom není. Můžete začít hned. Stačí vám pro to takové ty malé podlouhlé papírové kartičky, anebo jednoduchý Microsoft Excel, či Google Sheet.

Nejjednodušší variantu Product Backlogu si můžete představit jako kartičky  (jeden sloupec Excelu), kde jednotlivé funkcionality jsou například:

Automatický výběr piva na párty
Vybrat nové pivo na ochutnání
Objednat oblíbené pivo
Doporučit drahé pivo

Jak asi víte, nejčastější formou psaní Product Backlog Items je User Story. V takovém případě Backlog obvykle rozšíříte o jméno a takzvané Conditions of Satisfaction.

Jméno
UserStory
Conditions of Satisfaction

Automatický výběr piva
Jako Jon (zaneprázdněný manager) chci, aby mi “Beerer” vybral piva na párty, abych mohl různorodým výběrem oslnit přátele.
Jon překvapí své přátele výběrem z lokálních pivovarů po celém světě a pivy různých chutí.

Vybrat nové pivo na ochutnání
Jako Jon chci zobrazit katalog piv, abych si mohl vybrat nějaké nové pivo na ochutnání.
Jon může porovnat piva podle chutí přímo z katalogu.

Objednat oblíbené pivo
Jako vracející se zákazník chci vidět oblíbená piva, abych si je mohl znovu objednat.
(může zůstat prázdné – conditions of satisfaction nejsou nutná).

Doporučit drahé pivo
Jako vlastník obchodu chci, aby “Berrer” doporučovat přednostně drahá piva, abych měl větší zisk.
Zákazníci se necítí pod tlakem moc utrácet.

Popřípadě můžete ještě přidat několik volitelných položek jako: ID, Estimate, Epic, a Priorita.

ID PBI Estimate Epic Priority
234 Automatický výběr piva na párty 20 Order 1
556 Vybrat nové pivo na ochutnání 8 Order 15
123 Objednat oblíbené pivo 3 Order 40
89 Doporučit drahé pivo 5 Profit 50

No a to je vše. Jak vidíte, není na tom nic složitého, nic co by vyžadovalo žádné komplexní nástroje složitější než podlouhlé papírové kartičky nebo Excel Sheet. Zkuste a uvidíte.