logoZuzi's blog

Agile and Lean, Scrum, Kanban, XP @ Business

Zuzi's blog header image 1

CSM kurz

Certified LeSS Practitioner: Principles to Practices: 29.-31.3.2017, Praha
Certified ScrumMaster Training (Scrum Alliance): 30.-31.5.2017, Bratislava (anglicky)
Certified Scrum Product Owner Training (Scrum Alliance): 15.-16.6.2017, Praha
Certified ScrumMaster Training (Scrum Alliance): 19.-20.6.2017, Praha

Agilní a Scrum Transformace

15. 03. 2017

Agile

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

→ No CommentsTags:·····

Agilní Leadership

03. 03. 2017

Agile

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.

→ No CommentsTags:·····

Od koho a jaká Scrum certifikace má opravdu hodnotu

14. 02. 2017

Scrum

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, které dnes mají na trhu opravdovou hodnotu, protože stále za nimi stojí ti, kteří Scrum vymysleli, vydobyli mu uznání a participují na jeho aktuálnosti, ale hlavně proto, že drží kvalitu. 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. 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 jsou jen 2 možnosti: certifikace od Scrum Alliance či Scrum.org.

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. Jako další level je tu CSP – Certified Scrum Professional kde držitelé musí prokázat praktickou zkušenost se Scrumem. 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.

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.

Comments OffTags:

Nejlepší motivace

02. 02. 2017

Management

Nejlepší motivace, jak již věděli naši předci, je z dobře udělaná práce. V moderním světě na to často zapomínáme a zkoušíme motivovat lidi různými bonusy jako jsou dárky, peníze, růst v kariérním žebříčku. Zdánlivě to může fungovat, ale většina takových motivátorů jsou vlastně “demotivátory“. Tedy, když máte nedostatek peněz, cítíte se zneuznaně, nedostatečně ocenění, ať už penězi nebo pozicí, tyto faktory výrazně přispívají k vaší demotivaci. Když ale máte peněz dost, cítíte se ocenění okolím, máte pozici, kterou považujete za přiměřenou vaší práci a schopnostem, ani velkým přidáním platu, ani skokem o dva stupně v kariérním žebříčku větší motivace nedosáhnete. Krátkodobě budete mít radost, ale ta většinou rychle vyprchá. Naopak, vznikne-li u vás pocit, že odměna nebyla zasloužená, dlouhodobě demotivuje. Stejně jako úplatek.

Jak tedy motivovat zaměstnance? Dát jejich práci smysl, ukázat jim, že někomu pomohli, že dělali něco smysluplného, že pomohli změnit svět. Je to úplně jiný druh uspokojení, než přidání na výplatní pásce. Scrum je úspěšný právě proto, že vrací život do procesně orientovaných firem. Vrací jim smysl jejich existence. Přivádí zákazníka do týmu a pomáhá jim znovu definovat hodnotu, kterou jim firmy a jejich produkty přináší. A pravidelný feedback od zákazníků se transformuje na sílu, která zpětně pohání lidi vymýšlet ještě lepší řešení problémů zákazníků a posiluje jejich motivaci a dobrý pocit z úspěchu.

Když už uvažujete o něčem hmotném, co byste dali zaměstnancům, abyste posílili jejich sounáležitost s firmou, dejte jim zážitek. Existuje mnoho studií na dané téma. Co motivuje víc? 20.000 jako prémie k platu, nebo víkendový pobyt na zajímavém místě ve stejné hodnotě pro rodinu? Na to první si již za měsíc nevzpomenete. To druhé zůstane ve vzpomínkách nejen vás, ale i rodiny, a bude působit daleko větší silou než libovolné peníze. Má to jeden háček, když se zeptáte zaměstnanců, budou volit peníze. S tím, že si za ně koupí co potřebují, a že sami nejlépe vědí, co je baví. Zdá se to logické, ale bohužel to nepůsobí tak, jako když dostanou něco extra, něco, co by si sami nikdy nekoupili. Jako firma bych tedy vždy volila zážitek. Na závěr, žádné poukázky na fitness ani kulturu ani dovolenou to nenahradí. Něco v tom, co dělají úspěšné firmy jinak, je skryto v osobní vazbě. Unikátnosti. Vytvoření zážitku na míru. Je to něco jako když kupujete nejlepšímu kamarádovi dárek k narozeninám. Taky mu nedáte v obálce peníze, ani gastroturku, ale koupíte něco, co ocení. Že to stojí čas? No jo, stojí. Ale záleží vám opravdu na zaměstnancích, nebo si jen chcete odškrtnout, že jste něco udělali pro jejich motivaci?

Comments OffTags:··

Jak řešit chyby ve Scrumu?

18. 01. 2017

Scrum

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

→ 4 CommentsTags:····

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

03. 01. 2017

Scrum

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.

→ 4 CommentsTags:····

Jak naplánovat Sprint bez odhadů?

09. 12. 2016

Scrum

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.

Comments OffTags:······

Agilní Organizace

24. 11. 2016

Agile

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.

Comments OffTags:·····

Sprint Review

11. 11. 2016

Scrum

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.

Comments OffTags:······

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

26. 10. 2016

Scrum

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.

Comments OffTags:·····