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.

Žádný meeting ve Scrumu není klasický status meeting

Víte, že žádný meeting ve Scrumu není klasickým status meetingem?

Daily Scrum (Standup meeting)

Začněme Standupem, kde antipaternem je, že jednotliví členové týmu reportují, co všechno dělali a co dělat budou. Asi aby je ScrumMaster nebo ostatní členové mohli kontrolovat.

Standup je tu ale proto, aby se tým a jeho členové každý den rychle zastavili a řekli si, jestli jdou správným směrem a jestli ještě stále věří tomu, že zvládnou dodat Sprint Goal. Proto nekontrolujeme, čím trávili čas, ale soustřeďujeme se na to, co je hotovo, a jak budou spolupracovat na tom, co mají teprve dokončit.

Sprint Review

Dalším v řadě je Sprint Review, kde antipatern je prezentovat, které konkrétní UserStory se dokončily a které ne. Spousta týmů status dotáhla do dokonalosti a dokonce ukazuje prezentaci a jakési grafy a vyhodnocuje úspěch a neúspěch Sprintu.

Sprint Review je tu ale proto, abyste ukázali Potentional Shipable Product Increment – tedy to, co tým dokončil – zákazníkovi a získali na základě toho zpětnou vazbu. Ta je potom cenným vstupem pro Backlog Refinement a pomáhá vám dodat úspěšný produkt.

Retrospektiva

Do třetice je tu Retrospektiva, kde antipaternem je začínat Retrospektivu tím že procházíte jednotlivé body z minula a hodnotíte, jak se vám povedly dokončit a jestli zabraly na daný problém.

Retrospektiva ale má být kreativním workshopem, kde se tým zamýšlí nad tím, co by chtěli změnit, co jim vyhovuje, co naopak chtějí zlepšit. Aby fungovala, musíte se na sebe umět podívat jinýma očima, z venku. A když začnete statusem, tak ten nadhled ztratíte a v další fázi pak jen zopakujete, co vám zbylo z minula. Máte-li pocit, že se věci nehýbou kupředu, určitě to na další retrospektivě zazní znovu i bez opakování. A status těch pár Action Items z minula můžete dát na tabuli a skouknout na Standupu.

Proč je Backlog Refinement aktivita a ne meeting

Backlog Grooming se stal postupně velmi častou praktikou jak udržovat Product Backlog a rozumět jednotlivým User Stories. Týmy takový Backlog Grooming pořádají pravidelně jednou až dvakrát za Sprint, a trvá něco kolem 1-2 hodin. Když se ale podíváte na Scrum Guide, nikde se o takovém meetingu nic nedočtete. Jak tedy zajistit, že máme kvalitní Backlog a rozumíme mu bez Backlog Groomingu? Scrum Guide definuje pro tyto účely průběžně probíhající Backlog Refinement. Proč to není meeting? Protože všechny meetingy, kde musí být celý tým, jsou drahé. A když jsou dlouhé, obvykle nejsou ani moc efektivní.

Celý Backlog Refinement tedy můžete dělat jen jako sérii workshopů, kterých se účastní ti, pro které to zrovna dává smysl. Někdy je to jen malá skupinka složená z členů týmu, někdy se přidá Product Owner, jindy stakeholdeři. Vyjímečně se zúčastní všichni. Tyto workshopy děláme tak často jak je potřeba, abychom v každou chvíli měli připravený kvalitní Backlog na cca 2-3 Sprinty dopředu. Když tato aktivita probíhá dobře, tak všichni rozumí vizi produktu, vědí, jak se definuje business hodnota, mají přehled o velkých funkčnostech, které se chystají v budoucnu, a mají detailní porozumění toho, na čem budou pracovat v následujících Sprintech, jak co se týče business hodnoty tak představě o řešení problému. Jak poznáte, že je Backlog Refinement dobrý? Sprint Planning je potom jen rychlým checkem že víte, co v rámci Sprintu dokončíte, akceptace dokončených funkcionalit v rámci Sprintu Product Ownerem je formalitou, protože nevznikají nedorozumění a zákazníci jsou produktem, který na Sprint Review prezentujete spokojeni, a dávají zpětnou vazbu, která produkt zlepšuje, nikoli shazuje ze stolu.

Akceptační kritéria jsou ze starého neagilního světa

Akceptační kritéria jsou připravená odebrat se do starého železa. Už nejsou potřeba, a upřímně, nikdy to nebyl dobrý nápad. Byl to takový malý link, kterým se firmy snažily předstírat, že jsou agilní, ale mohly stále mentálně a mindsetem zůstat ve starém klasickém světě. Akceptační kritéria jsou totiž pozůstatkem detailní specifikace, kdy vývojář – rozumějme coding monkey – aby mohl začít pracovat, musel dostat detailní popis chování a řešení. Říkali jsme těm rozsáhlým dokumentům requirements a specifikace. A bez ní ani kuře nehrabe a vývojář nedá ruku na klávesnici.

Jak to že najednou nejsou potřeba? No ony vlastně nikdy nebyly. Ale zvyk je železná košile. Dělali jsme to tak vždy a tak proč v tom nepokračovat. Dodávaly nám jistotu. Měli jsme díky akceptačním kritériím pocit, že věci máme víc pod kontrolou. Že je můžeme vzít jako checklist a na konci Sprintu odškrtat, že jsme udělali vše, co bylo v zadání. Bohužel to nám ale nepomáhalo v tom mít fokus na dodání hodnoty, a týmy často jen dodaly, co tam bylo zadáno, a nepřemýšlely, jestli dosáhneme požadovaného efektu u zákazníka a v produktu.

Co tedy dělat aby to celé fungovalo? Celý tým by měl mít jasnou představu o tom, co za produkt dělá, které věci jsou z pohledu našeho businessu důležité a které ne. Toho se dá docílit tím, že se tým zapojí do visioning workshopů v rámci Backlog Refinementu, věnuje se nejen technologii, ale porozumí zákazníkovi a jeho potřebám. To je něco, o co se v Agilu snažíme už od začátků s Extreme Programmingem, kdy tím nejextrémějším kouskem XP bylo mít zákazníka v týmu. V momentě kdy tým porozumí celkovému smyslu produktu, mohou se začít podílet na jeho rozvoji. Teprve tehdy jsme vytvořili tu pravou end to end vazbu na zákazníka a změnili své vnímání vývoje softwaru z kódování na dodávání hodnoty pro zákazníka. A pak už můžeme s klidným svědomím použít User Story as a Card – tak jak byla vždy definovaná, kde důraz není kladen na detailní popis chování, ale na business hodnotu kterou dodáváme. Proto se nám vše, co potřebujeme vědět, v pohodě vejde na malou podlouhlou index kartičku. Detaily, jak této hodnoty dosáhneme, vznikají v rámci konverzace o funkcionalitě v průběhu Sprintu v době, kdy na dané UserStory tým pracuje. Výhoda konceptu UserStory as a Card je to, že udržuje Backlog jednoduchý, klade důraz na konverzaci a pomáhá týmům spolu Product Ownerem proritizovat a dodávat tu nejdůležitější hodnotu nejdříve. Kdybyste stále měli pocit, že je škoda nechat druhou stranu kartičky pro User Story prázdnou, zkuste tam napsat tzv. Conditions of Satisfaction. Rozdíl je, že takto definovaná kritéria úspěchu nejsou seznamem, co to musí dělat a jak, ale co se má stát až to naimplementujeme. Tedy jaký má věc vzbudit v zákazníkovi pocit, co má udělat, jak má produkt používat.  Je to takový funkční test, který pomáhá lépe definovat možný směr řešení, ale stále nechává volnost jak danou UserStory vyřešit.

Jako John,
si chci vybrat piva na párty,
abychom měli zajímavý výběr pití.

Akceptační kritéria by mohly vypadat následovně:

  • Výběr podle zemí, značek, druhů a chuti
  • Full text vyhledávání
  • Omezení ceny

Takto definovaný list v podstatě definuje řešení a tým už to jen slepě naimplementuje.

 

Na rozdíl od toho, když píšeme Conditions of Satisfaction, zaměříme se na hodnotu:

John vidí, nakolik jsou vybraná piva různorodá, a dostává doporučení na další piva do výběru.

Tento příklad dává větší možnost řešení ovlivnit a vymyslet něco kreativního a v podstatě dodefinovává UserStory. Zároveň se na danou funkcionalitu dívá z pohledu zákazníka, což je vždy dobře. Jak jistě víte, zákazník nemusí být vždy koncovým uživatelem, např:

Jako Beer Shop CEO,
chci zákazníkům nabízet prioritně dražší značky,
abychom měli větší zisk.

 

Conditions of satisfaction pak mohou vypadat následovně:

Zákazníci nabídky často využijí, ale necítí se pod tlakem kupovat drahá piva.

 

Takhle definované parametry úspěchu mimo jiné donutí tým napsat nějaký trackovací mechanismus jak sledovat kolikrát a kteří zákazníci nabídky využili a funkcionalitu na základě toho upravovat a zlepšovat.

Asi je to běh na dlouhou trať a nejde do něj naskočit hned. Ale je to směr, ke kterému bychom se jako industry měli blížit. Jedině tím směrem lze dosáhnout je pravé Agility a úspěchu.

Konference Agile Prague 2016

Již pošesté se v září koná konference Agile Prague. Můžete se tedy těšit ve dnech 12.-13. září 2016 na spoustu zajímavých přednášek s Agilní tematikou, praktické case-studies a také několik workshopů. Co konkrétně bych doporučila?

Mám radost, že letos přijede Gojko Adzic, jehož Impact Mapping je velmi užitečný ve všech produktových organizacích.  Těším se na Woody L. Zuilla a jeho Mob programming. Další letošní keynote přednášku bude mít David Laribee na téma The Liberal Arts Programmer. Poslední letošní keynote řečník je Mark Layton, Scrum trenér s kterým jsme vloni organizovala v Praze Globální Scrum Gathering.

Stále žhavé téma je jak použít Scrum v kontextu větší firmy, tedy Scaling Scrum. V loňském roce Bas Vodde přestavil v Praze LeSS (Large-Scale Scrum) Framework a letos na něj naváže Jurgen De Smet, certifikovaný LeSS trenér, se kterým organizujeme následný konferenční workshop právě na téma LeSSu. Když už jsme u LeSSu, tak i Ran G. Nyman se scalingu a LeSSu věnuje.

Letos se věnujeme hodně i témau komunikace (Judith Mills) a coaching (Lisa Cornier a Suzanne Gagnon). Jako tradičně na konferenci bude Open Space, tentokrát ho uvede Olaf Lewitz, z čehož mám radost, protože Olaf vždy mile překvapí s něčím novým. Těším se také na přednášku Danka Kovatche a jeho pohled na Scrum. Gil Zilberfeld má hned dvě přednášky na téma testování a ty si určitě nenechte ujít. Jako každý rok vám několik firem představí své zkušenosti s aplikací Agilních metod, Scrumu a Kanbanu.

Já mám připravený krátký workshop na téma Team Toxins, kde se podíváme jak by měl dobrý tým vypadat a co dělat když náhodou tak dobrý není.

Nebudu tu opisovat celý program, na ten se podívejte na stránky konference AgilePrague. Doufám, že každý z vás si najde svá témata, která vám přijdou zajímavá. Nezapomeňte že inspiraci nezískáte jen posloucháním přednášek, ale i osobní konverzací se speakery a účastníky konference. Prostoru pro networking a diskuze bude hodně a využívejte ho co možná nejvíce. I o tom je konference Agile Prague.

Těším se na konverzace, přednášky a workshopy, ale hlavně na vás všechny – účastníky Agile Prague conference.

 

Co je to produkt a co projekt

Projekt začíná a končí. Produkt je tady ‘donekonečna‘. Pokračuje dalšími fázemi, rozšiřuje se, mění se.  Definice, kterou používá LeSS (Large Scaling Scrum) říká, že produkt by měl být tak široký jak je jen možné, ale stále praktický. Praktičnost obvykle končí hranicemi vaší firmy. Když už byste museli do cross-functional týmů zakomponovat lidi z cizích firem, abyste mohli dodávat end to end funkcionalitu, tak jste asi na hranici produktu. Na druhou stranu, jestliže produkt vnímají zákazníci jako jeden produkt – je to jeden produkt bez ohledu na technologii. Tedy frontend a backend je jeden produkt. Internetové řešení obsahující Web, iPhone a Android aplikaci je jeden produkt. Z druhé strany všechno co má podobný kód a je technicky podobné je jeden produkt.

Továrna na párky

Firmy často nevědí, kdy se na to co dělají, mají dívat jako na jeden produkt (viz výše zmíněná kritéria) a kdy to naopak rozdělit na více celků. Analogie, kterou pro takové rozhodnutí používáme, se jmenuje Továrna na párky. Chodí k vám různé zakázky-projekty. Někdo chce hovězí párky na večeři, někdo grill mix na párty. Někdo chce dokonce vegetariánský párek, někdo pikantní chilli. Když se na to budete dívat projektově, nikdy nepostavíte stabilní cross-functional týmy. A Agile vám nikdy pořádně nebude fungovat. Když ale řeknete, že vaše továrna na párky je továrna na internetová řešení, a na projekt se budete dívat jen jako na velký Epic v Backlogu, bude vše najednou snadné. Máte jeden Backlog, tam se sypou veškeré projekty. Jako každá položka Backlogu prochází Backlog Refinementem a prioritizací. Týmy pak jen berou ty nejdůležitější položky z Backlogu a dodávají je v rámci svého procesu v kvalitě odpovídající Definition of Done.

Když to mám nějak sesumarizovat, většinou produkt proti současnému stavu rozšiřujeme a stavíme stabilní továrnu, kde týmy mohou spolupracovat na jedné věci. Na druhou stranu takových továren můžete mít ve firmě mnoho. Například když děláte online hru a informační systémy, asi je praktické aby to byly dvě továrny a ne jen jedna.

Jak takovou velkou továrnu organizovat? Na to odpovídá například Large Scaling Scrum LeSS –kdybyste se chtěli o LeSS frameworku dozvědět více, pořádáme 3 denní LeSS workshop při konferenci Agile Prague 2016 v září.