Retrospektiva – Časová osa

V předchozích příspěvcích jsem doporučovala retrospektivu jako zcela zásadní praktiku agilních metod a Scrum procesu. Ideální je začít retrospektivu kolečkem, kde každý člen týmu identifikuje co se mu líbilo a co ne. Když už vás tento formát omrzí, můžete posílit vnímání reality tzv. hvězdou. Obě tyto metody nechávaly popis situací a pocitů až na retrospektivní meeting. Další metodou je časová osa, která dává možnost pojmenovat pozitivní i negativní události už v průběhu Sprintu.

Připravte si následující časovou osu a barevná lepítka a nechte tým zapisovat jejich pocity hned, jakmile daná situace nastane. Na retrospektivu potom dostanete podobnou časovou osu s událostmi, tak jak je jednotliví členové týmu zaznamenali. Červené lístečky hodnotil pisatel jako negativní, zelené jako pozitivní, oranžové jako něco mezi, co ale stojí za zmínku. Zároveň se dá říci, že čím výš je kartička umístěná, tím důležitější je. Ale ostatně stanovte si na to vlastní pravidla tak, aby tým bavilo kartičky vymýšlet a lepit na časovou osu.

Na začátku retrospektivy nechte každého člena týmu udělat tečku pro každou kartičku, aby se mohl vyjádřit, jak danou událost viděl on.

Následně projdete jednotlivé události a jako u kolečka nezapomeňte, že retrospektiva funguje jen tehdy, když jako její výsledek jsou akce, dohody a pravidla. Retrospektiva musí měnit zaběhnuté procesy, musí dát lidem možnost se poučit z toho, co fungovalo i z toho co se úplně nepovedlo. Scrum proces zavádí retrospektivu jednou za Sprint, a věřte, že to není ztráta času.

Časová osa má mnoho výhod. Obvykle odbourává formalismus, retrospektiva je zábavnější. Část kartiček na tabuli bude určitě jen pro zasmání. A o to možná jde. Vzpomenout si i na drobnosti které nemají žádný zásadní vliv na projekt, ale stmelují tým dohromady. Retrospektiva tím dostává větší dynamiku a je snazší zapojit všechny členy týmu.

Retrospektiva – Hvězda

Jak již jsem psala, retrospektiva je asi nejdůležitější praktikou agilních metod a nedílnou součástí Scrum procesu. Protože, aniž byste se učili a vylepšovali a upravovali Váš proces, nikdy nebudete dostatečně agilní, ale ani efektivní, kvalitní a úspěšní. Při retrospektivě si uvědomíte, co jste dělali dobře a co ne. Co je třeba změnit a co naopak dělat i příště.

Další možnost jak dělat retrospektivu je takzvaná hvězda. Když už Vám základní framework tzv. kolečka přijde moc nudný, nechte lidi napsat jejich pocity na lístečky a ty následně umístit do kategorií dle následujícího obrázku: Stop Doing, Less Of, Keep Doing, More Of, Start Doing.

Retrospektiva - hvězda

I taková jednoduchá klasifikace občerství retrospektivu. Donutí všechny jít více do detailu a opravdu se zamyslet nad tím, co bychom chtěli začít dělat, co naopak dělat nechceme vůbec, co omezíme, co posílíme a v čem budeme pokračovat.

Nezapomeňte, jsou to pocity jednotlivých lidí a jako k takovým by se k nim také mělo přistupovat. Nikdo si nečiní nárok na universální pravdu. Všichni mají stejné právo se vyjádřit. A jenom tím, že se naučíte si vzájemně naslouchat, se stanete efektivnějšími. Zmizí zbytečné problémy a nedorozumění. A práce Vás bude více bavit. Retrospektiva musí vést k akcím, pravidlům, změnám. Nenechte ji tedy jen tak rozplynout do ztracena.

Scrum proces není všemocný

Scrum proces se zdá být jednoduchou náplastí na všechny problémy. Nefunguje Vám tým? Začněte používat Scrum. Jste zahlceni byrokracií, Scrum Vás jí zbaví. Máte málo kvalitní kód, a pořád něco předěláváte? Netestujete? Zákazník není spokojen s tím, co dostal? Scrum má řešení. Tak se pojďme podívat, jak modelové firmy Scrum proces nasazují.

1. Technokrat s.r.o

Ředitel pověří někoho ze zkušenějších teamleaderů či vývojářů v týmu aby zjistili, o co jde. Ten si udělá research. Možná si koupí knihu, ale internet většinou stačí. Všechno umíme a víme, tak začneme. Scrum meeting (daily standup) je zdánlivě jednoduchý a chcete-li dělat Scrum, tak ho prostě musíte mít. Zároveň je ale třeba hledat tool, protože kartičky se používaly maximálně před sto lety. Čím složitější tool je, tím více možností má, ty všechny by se nám mohly hodit. A výsledek je, že tým brblá, že je to všechno k ničemu, proč tráví denně hodinu na meetingu který nic nepřináší, že své práce má dost. Toolu nikdo nerozumí, a Scrum metodě také ne. Navíc produktivita výrazně klesla a zákazník se také netváří nadšeně. Zeptáte-li se na Scrum metodu, dozvíte se, že Scrum my známe a děláme, ale my jsme v tom a tom jiní a pro nás se Scrum proces nehodí a nejde vlastně použít.

2. Developper s.r.o

Vývojáři o Agilních metodách nebo Scrumu nebo XP zaslechli někde od jiných týmů. A líbí se jim to. Nikdo by jim přeci nerozkazoval, nikdo by jim neříkal, co mají dělat a jak. Plánuje přeci tým, a to jsou oni. Cool. Tak začnou jednotlivé praktiky dělat. Většinou to selže v napojení na management. Někdy už na úrovni teamleadera, někdy až u top managementu. Spousta managerů v Čechách je ze staré školy. Bojí se dát své pseudozodpovědnosti na ostatní. Bojí se, že by někdo mohl vědět, co a jak dělají. A co se chystají dělat. A že by vše neměli pevně v rukou. A tak je lepší praktiky Scrumu omezit, okleštit nebo zakázat. Ale ne přímo, oni dělají Scrum, ale vidíte, dali jsme jim šanci, a ono to mělo takové problémy…

3. Korporát a.s.

Scrum proces a agilní metody používají velké firmy okolo nás. Měli bychom ho zkusit. Pošleme týmy na kurzy, project managery na certifikaci Scrum Mastera, a změníme procesy. Týmy tedy začnou, a až do prvního většího problému vše funguje. Pak ovšem project manager zapomene, že má jinou roli, a že jako Scrum Master nesmí měnit plán, nesmí rozhodovat za tým, a rychle se vrátí k osvědčeným metodám řízení projektů, na které byl zvyklý. A celá firma prochází deziluzí. Dalo by se říci, že devět z deseti project managerů se na Scrum Mastery nikdy nepodaří přeučit.

Existují i úspěšné firmy. Velké i malé. Ty většinou pochopili, že Agilní metody a Scrum představují změnu myšlení a přináší změnu kultury firmy. Investovali do kurzů, našli si interního či externího kouče aby jim s transformací pomohl. Vědí, proč změnu chtějí a co od ní očekávají. A vědí, že změna je náročná a vyžaduje hodně každodenní práce na každé úrovni. Taková změna nejde nařídit zhora, ani partyzánsky vybudovat odspodu. Musí propojit celou firmu. Stojí hodně energie. Ale výsledek pak stojí za to.

Co mi přineslo WebExpo 2010 – část 5

Paul se věnoval tomu, jak prodávat Agile. Je dobré si uvědomit, jak se cítí project manager, jak obchodník a jak zákazník? Co jsou jejich cíle? Co potřebují a proč? Např. u Waterfallu se projektový manager cítí přinejmenším do poloviny projektu skvěle. Ano, na začátku stálo hodně úsilí vše rozmyslet a rozplánovat. Ale teď už jedeme podle plánu. A skvěle to jde. A i kdyby, na konci projektu je ohromný buffer – víte, jak se jmenuje? Testování. Vše je přeci dobře vymyšleno, programátoři píší dobrý kód, tak k čemu by nám u takto dobrého kódu vlastně to testování bylo? V nejhorším se koupí na sobotu pizza a uděláme velký testovací den. A na konci projektu? Uff, to jsme rádi, že je to za námi… Hlavně žádná reflexe, už na to nechceme ani pomyslet. Tohle všechno agilní metody mění.

Chcete-li být úspěšní ve vysvětlování agilních metod, naslouchejte zákazníkovi, ukažte, že rozumíte jeho problémům a potřebám a že jsou pro Vás opravdu důležité. Dokažte jim, že víte co je pro ně důležité. Většina zákazníků bude ráda s někým takovým spolupracovat.

Co se týče kontraktu, stačí vám jedna stránka. Co je na ní obsahově? Definované dvě smluvní strany a cena za dodávané služby. V několika velmi stručných větách ošetřuje kvalitu a podmínky kontraktu, vlastnictví a případné změny kontraktu. Je to hodně inspirativní. Zvláště pracujete-li pro velké korporace či znáte jejich smlouvy.

Co mi přineslo WebExpo 2010 – část 4

Andrea začal svoji přednášku prohlášením: It’s not a technology which makes a difference. Tedy že technologie Vám k úspěchu nepomůže. Potřebujete něco víc. Leadership.

Zamyslete se nad tím v kolika případech manageri okolo vás používají jen tyto dva základní nástroje: Hůl a mrkev. Všechny bonusy jsou o tomto principu. A funguje to? Jen v krizových situacích. Ale většina firem není 100% času v krizové situaci, nebo by alespoň neměli být. A nic jiného z oblasti řízení lidí a motivace neznají.

Andrea Provaglio

Andrea měl výbornou hru kdy nechal účastníky zažít, jak se manageri většinou chovají, a jaké to má následky. Co se stane, když je někdo ze systému náhle odebrán, a teď se všichni tváří, že ten člověk nikdy ani neexistoval (Týna v tomto případě z ničeho nic odjela do Dánska a nový manager přišel a nikdo nevěděl proč). Myslím, že se to musí zažít. Dobré na tom je to, že i když nový leader je slabý a vlastně ani leaderem není, systém si najde neformálního leadera a vše funguje dál. Jen ne tak dobře. I pro nového leadera navázat na existenci předchozího leadera a třeba i věci změnit, než se tvářit že ten před ním nikdy neexistoval. Dejte si fotku týmu na nástěnku ke kávovaru a až se někdo zeptá kdo to je, je snadné odpovědět to je Týna, Týna je teď v Dánsku ale předtím to byla naše managerka. Konzistence týmu není narušena. A vše funguje dál.

Na závěr ještě vzpomenu Andreovu radu, že nemůžete úspěšně nasadit Scrum ve firmě kde chybí leadership. Všechnoživé je vždy samoorganizující se. Jen se to často organizuje jinak, než bychom to rádi viděli. Co je tedy největším problémem obecně? “Overusing technical mind“…

Co mi přineslo WebExpo 2010 – část 3

WebExpo, tedy agilní sekce konference o které teď volně píšu zážitky, mi přineslo i překvapení, že někteří z přednášejících berou agilní praktiky velmi striktně. Třeba Boris říkal, že ScrumMastera prostě musíte mít na full time na projektu. Zdůvodnění dávalo smysl, říkal, že ScrumMaster zefektivní tým o více jak 100% a tedy se ta investice hned zaplatí. Ovšem jeho odpověď na otázku co dělat když mám malý tým – radil, že mám dva týmy pracující pro různé zákazníky spojit do jednoho – mi už úplně realistická nepřipadala. Působilo to hodně procesně orientované, bez ohledu na realitu. Ideální svět neexistuje. Je dobré znát ideální řešení, ale je dobré ho i upravit když toto ideální řešení z nějakého důvodu nelze použít. Asi mi byl bližší přístup Davida, který říkal, že když praktikujete stand-up meeting, rozumíte jeho cílům, víte jak se má dělat, ale nepřináší vám očekávanou hodnotu, tak je pro Vás možná lepší ho nedělat vůbec, protože třeba není pro Vás.

Odhlédneme-li od spíše filozofické diskuze jestli se musíme spíše my přizpůsobit praktikám, či raděj přizpůsobit praktiky, Boris vysvětloval poměrně často zmiňovaný problém co dělat s tím, že některé úlohy potřebují nejprve strategicky rozmyslet a teprve potom se můžou implementovat. Následující obrázek ukazuje, jak se na danou problematiku můžete dívat z pohledu velocity. Jednou z možností je samozřejmě ohodnotit i tyto strategické práce, ale na druhou stranu, to že jeden den rozmýšlíte co dál, nemá pro zákazníka žádnou konkrétní prezentovatelnou hodnotu. A tedy je těžké to nějak ohodnotit. Proto mě zaujal princip navržený Borisem, který doporučoval počítat jen hodnotu pro features (zelená) a nikoli hodnotu kterou jsme věnovali strategickému rozvažování co a jak dál. Následující obrázek ukazuje, co mám na mysli.

StrategicAspects-Velocity

Na závěr dodávám, že se chystám na Borisem vedený certifikační kurz CPO – tedy Certified Product Owner, a jsem tedy docela zvědavá, co mi takový kurz přinese. Ale o tom zase příště.

Co mi přineslo WebExpo 2010 – část 2

Abych pokračovala v načatém popisu Agilní sekce WebExpa kterou jsem pořádala:

Hodně speakerů se zaměřovalo na proces učení, protože bez učení se nemůžete zlepšit, a nechcete-li se učit, nemá smysl dělat retrospektivu, být iterativní, v podstatě ani být agilní. Yves říkal, že na to, abyste byli v něčem opravdu dobří, potřebujete 10 000 hodin tréningu. Ani sportovci se nestanou hvězdami přes noc. Musí se učit a zkoušet to znovu a znovu. A retrospektiva je ideálním nástrojem na učení se.

Když máte stabilní tým, ve kterém vše funguje a retrospektiva začíná být nudná, vezměte na Vaši retrospektivu managera či externího zákazníka. Třeba zjistíte, že z jejich pohledu už to tak skvěle nefunguje, a že se stále máte co učit a v čem se zlepšovat.

Máte-li problém, že ne všichni se do retrospektivy zapojují, zařiďte, ať všichni musí promluvit během prvních 5minut retrospektivy. Bude pro mě pak snazší se zapojit.

Mějte respekt k těm, co tam nejsou, vždycky bude někdo chybět a příště to můžete být i Vy.

A poslední dobrá rada k retrospektivě, jedním z dobrých nápadů je říct něco dobrého o kolegovi. Může to být to snazší, než chválit sám sebe a přinese to retrospektivě nový rozměr.

Co mi přineslo WebExpo 2010 – část 1

WebExpo 2010 mělo letos oproti minulým ročníkům sekci zaměřenou na agilní metody. Když bych měla hodnotit úspěch agilní sekce, kterou jsem po programové stránce celou organizovala, myslím, že splnila má očekávání. Úroveň přednášejících byla dobrá, přednášky zajímavé a témata různorodá. Lidí přišlo hodně, něco mezi 60-100 účastníky. Tedy se zdá, že agilní metody zajímají hodně firem. Nemá smysl opakovat, co bylo na WebExpu řečeno, ale ráda bych se podělila o pár zajímavých myšlenek, které přednášky přinesly mě osobně.

Panel Discussion at WebExpo 2010 - Andrea, Lubos, Paul, Alex, Maria, Pierluigi (from the right)

Davis Hussaman mi mluvil z duše, když říkal, že Scrum není dogma. Není to žádné náboženství, které byste měli slepě následovat bez toho, aniž byste pochopili smysl Vašeho počínání. Lidé ve spoustě firem “chtějí Scrum“ ale málo z nich přemýšlí, proč ho vlastě chtějí a co je jejich cílem. A to nemluvíme ani o tom, že cíl se často někam posouvá a mění a možná právě proto jsou iterativní metody úspěšnější než ty klasické, kde všichni očekávají, že to co si jednou rozmyslíte tak bude navěky věků.

Další zajímavou myšlenkou bylo, že co neznáte, Vás bolí nejvíce. A jsme zase zpět u toho proč je vlastně Scrum iterativní. Abychom se pravidelně zastavili, udělali reflexi, něco se naučili, něco změnili, zrevidovali, jestli je cíl ještě stále tam kde si myslíme, a co se nám to vlastně děje. Protože víte-li že nestihnete projekt dodat včas již v polovině projektu, máte pořád ještě spoustu možností to napravit (přidat resourcy, omezit funkcionalitu, vyjednávat, … ). Ale zjistíte-li to až těsně před odevzdáním, máte jen velmi omezené možnosti s tím cokoli udělat.

Víte co je nejčastější metodologie řízení projektů? ‘Hope methodology‘. Všichni do jednoho nakonec jen doufají, že projekt bude úspěšný a že to nějak stihnou.

A nečekejte, že někde najdete best practices jak zavádět agilní metody. Best practices fungují na jednoduché situace jako je pečení dortu. Ale proces zavádění agilních metod je komplexní a komplikovaný. Jediné co Vám pomůže je mít vizi a jasný cíl a tuto vizi sdílet s celým týmem či firmou. Ale taková vize většině firem chybí a možná přesahuje rámec jejich myšlení. A tak se raději zaměřují na jednotlivé praktiky. Je to jako již zmíněné náboženství, kde se vize vytratila…

Ostatně když nevíte, kam směřujete, je snadné minout cíl i kdyby Váš iterativní proces byl sebelepší.

Ještě jedna větu jsem si poznamenala: Lidé nechtějí špatné produkty včas. Tedy jestli si říkáte, že dodržíte termín za každou cenu, a že to zákazník ocení, nemusí to tak být. Zákazník bude většinou radši, když dostane to, co potřebuje, i kdyby to mělo být o pár dní později. Zvláště když tuto skutečnost ví s předstihem.

Pozvánka na WebExpo 2010

Ráda bych Vám doporučila Agilní sekci na letošním WebExpu, kterou po programové stránce organizuji. Jedná se o v českých podmínkách unikátní akci, kterou by si neměl nechat ujít nikdo, kdo se o agilní metody zajímá.

Konference WebExpo 2010 v září

Třetí ročník konference WebExpo přináší novou sekci zaměřenou na agilní metody. V posledních několika letech výhody agilního přístupu oceňuje čím dál více firem a začínají být často používané i v českých společnostech. Agilní metody se zaměřují na týmovou spolupráci, zavádí efektivní procesy a posilují kvalitu produktu. Agilní sekce WebExpa je vyjímečnou příležitostí dozvědět se více o agilních metodách a vytváří unikátní platformu pro sdílení zkušeností z firem, které agilní metody úspěšně používají, s agilními metodami začínají, či o agilních procesech teprve uvažují.

Během dvou dnů přednášek promluví deset zahraničních odborníků z praxe, přednášky budou zaměřeny jak pro začátečníky tak i pro pokročilé, budou zaměřené na konkrétní agilní praktiky používané vývojáři, testery a teamleadery, ale zhodnotí i význam agilních metod pro managery firem. Program doplňují i dvě panelové diskuze, které jsou výbornou příležitostí konfrontovat vaše zkušenosti s odborníky z českých i zahraničních společností.

Čtvrtek je tradičně vyhražen praktickým půldenním workshopům, kde si můžete vyzkoušet Theory of Constraints spolu s Pierluigi Pugliese, který tento workshop povede. Pierluigi začínal jako programátor v telco sektoru, postupně přešel do role teamleadera a dnes se primárně věnuje konzultacím v různých firmách, kde pomáhá se zaváděním agilních metod. Pierluigi je původem z Itálie a dnes žije v Německu. Kromě již zmíněného workshopu bude mít i přednášku na téma Soft Skill Essentials for Software Craftsmen.

Dalším z pozvaných speakerů je charismatický David Hussman z Minnaepolis, USA, který agilní sekci konference v pátek zahajuje. David je jeden z nejlepších odborníků na agilní metody, organizuje lokální agilní komunitu v USA, pomáhá různým firmám v nasazování efektivních agilních procesů. S důrazem na pochopení aktuální situace daného projektu se vyhýbá obecným a universálním řešením, která jsou často doporučována. David pracuje v těsné spolupráci se softwarovými týmy, vývojáři, teatery i teamleadery. Jeho přednáška Products and People over Process and Dogma je ideálním tématem k zamyšlení nad smyslem agilních metod. Jak David říká v úvodu přednášky – čím dál tím více lidí tráví čas diskuzemi o tom, co to znamená agilní, místo toho aby jednoduše začaly agilní praktiky používat.

Další z přednášek je o tom, jak správně dělat retrospektivu. Jestli se rozhodnete s agilními metodami v praxi začít, retrospektiva by měla být první metodou, kterou do svého týmu zavedete. O problémech retrospektivy bude mluvit belgičan Yves Hanoulle, který je zkušeným agile coachem a jeho přednáška How to make your retrospectives the heart of your agile proces by Vám rozhodně neměla uniknout.

Mezi dalšími pozvanými odborníky je v německu žijící Boris Gloger, kerý kromě plánovaného workshopu bude mluvit v přednášce Scrum for Executives – Six Secrets for Success with Scrum o tom, jak používat Scrum v různých prostředích. Ital Andrea Provaglio se ve své přednášce Beyond Agile podělí o zkušenosti se zaváděním Scrumu. Nenechte si ujít ukázku, jak prodávat agile, kterou bude prezentovat Američan žijící v Polsku Paul Klipp ve své přednášce Selling Agile. O své zkušenosti z praxe se s vámi podělí i Maria Diaconu a Alex Bolboaca z Rumunska v přednášce Software Development = Learning.

Z českých speakerů představí Tomáš Pergler praktickou studii z firmy Seznam.cz, kde se podělí o zkušenosti Seznamu se Scrumem – A Year with Scrum in Seznam.cz. Dalším z českých speakerů je Luboš Král, který se v přednášce Agile acceptance and implementation by East and Western mindsets zaměří na otázky spojené s nasazováním agilních metod v multikulturním prostředí, jak převzaté techniky fungují v české kultuře, co se osvědčilo a co je naopak nutné změnit. Na ukázkách z praxe poukáže na hlavní rozdíly mezi agilními přístupy a klasickými metodami.

Konferenci doplňují dvě panelové diskuze, kde první je zaměřená na Agile z pohledu managementu. Podíváme-li se na největší překážky v zavádění agilních metod, nepochopení managementu bude jednou z nejčastějších příčin jejich neúspěšného nasazení. Pojďme se tedy společně s managery předních českých firem podívat na agilní metody z pohledu jejich managemetu. Diskutovat budou Zuzana Šochová (Managing Director, Lotofidea), Vlastimil Pečínka (R&D Director, Seznam.cz), Jan Bezdíček (Director, Rockwell Automation), Pavel Šuk (Vice President, Kerio Technologies), Martin Rýzl (Software Engineering Manager, Sun Microsystems).

Budete-li mít i po všech vyslechnutých přednáškách nějaké dotazy, panelová diskuze Everything you’ve ever wanted to know about agile methods je ideálním místem pro jejich zodpovězení. Všichni přednášející agilní sekce Vám budou plně k dispozici. Takže přijďte a zeptejte se na vše, co jste kdy chtěli vědět o agilních metodách.

Konference WebExpo se koná již tradičně na půdě ČZU v Praze, tentokrát již 23-25.9. Více informací se dočtete na každý den aktualizovaných stránkách WebExpa.

Scrum hra

Plánujete školení Scrum metody a přemýšlíte, jak nejlépe zajistit aby si účastníci co nejvíce zapamatovali? Kolikrát jste se vrátili z kurzu a školení, nadšeni jaké to bylo zajímavé, a už po několika dnech jste vlastně nevěděli, o čem to bylo. Říká se, že lidé se nejvíce učí z vlastní zkušenosti a prožitku. Testy na toto téma uvádějí, že si člověk zapamatuje jen přibližně 20 % z toho, co slyší, a pouhých 30 % z toho co si přečte nebo je mu názorně ukazováno. Ale již 50 % informací si zapamatuje, pokud má možnost nabízené informace vidět i slyšet. Kolem 70 % informací si pak člověk zapamatuje, když má možnost něco vidět, poslouchat a následně o tom navíc hovořit. Pokud k těmto třem činnostem přiřadíme ještě možnost aktivního vykonání, získáváme až 90 % šanci si dané informace zapamatovat [Soňa Hermochová, Teambuilding; Grada, 2006]. Tedy chcete-li naučit někoho Scrum, musíte mu vysvětlit jak na to, ale to nestačí. Aby to celé mělo smysl, musí si účastníci Scrum vyzkoušet na vlastní kůži a zpětně zhodnotit jak jim to šlo, co bylo dobré a co by měli naopak příště vylepšit.

Her se dá hrát mnoho, mohou být různě složité a komplexní, ale v podstatě jde o to, vyzkoušet si pár základních principů – Plánování, týmovou spolupráci, komunikaci se zákazníkem, reakci na změnu. A retrospektivu. Jednou z možných her zaměřených na prožitek ze Scrum procesu jsme navrhli s Petrem Olmerem stavbu železnice. Základem je postavit železniční spojení mezi městy USA a dovést zákazníka kam potřebuje/chce. Produkt backlogem je vyhlášen cíl spojit města A, B a C. Tým si zvolí ScrumMastera a hra může začít. Každý sprint si tým po diskuzi se zákazníkem naplánuje Sprint Backlog v závislosti na daných prioritách. Pak si každý člen vytáhne kartičky určující jeho rychlost, a případnou změnu celkových bodů. Tyto individuální rychlosti se sečtou a tým prezentuje, kolik železnice postavil. Cílem je mít funkční produkt a spokojeného zákazníka.

Potřebujete:

  • Mapu USA s před vyznačenou trasou – my jsme zvolili tuhle. Za jednu user story se považuje dokončení úseku z jednoho města do druhého (města jsou označena čísly). Stavba jednoho lomeného úseku trati odpovídá 4 bodům.
  • Lepítka na jednotlivé user story v backlogu.
  • Tabuli rozdělenou na tři části: Backlog | In Progress | Done.
  • Kartičky s rychlostí, které byl daný člen týmu schopen dosáhnout, které můžou vypadat třeba takto:
    • Proslýchá se, že nejpracovitější dělník dostane prémii, zkusím pracovat víc – 10
    • Odbory prosadily kratší pracovní týden – 5b
    • Je Den Železničářů, v poledne se jde do hospody – 4b
    • Včera pršelo, vypili jsme moc rumu – 3b

    Ale také třeba takto:

    • Měřiči špatně vykolíkovali trasu: +5b nová úloha: bourání špatně postaveného úseku – 3b
    • Vichřice povalila stoletý dub: +10b nová úloha: odstranění stromu – 0b
    • V tomto případě se do backlogu přidá nová úloha, která se musí z odpracovaných bodů dokončit jako první a pak je teprve možné pracovat dál na naplánovaných úlohách.

  • Větší hodiny měřící délku Sprintu, my jsme zvolili:
    • 5min – pre-planning & planning – tým na tabuli naplánuje user stories pro daný sprint
    • 5min – vyhodnocení & customer demo – každý člen týmu si vylosuje kartičku s rychlostí a podmínkami ve kterých daný sprint pracoval, Scrum Master je zodpovědný za zpracování výsledků a zorganizování customer dema.

    Nestihne-li tým všechny úkony včas (plán, vyhodnocení, customer demo, …), nejsou mu jinak hotové úseky uznány.

  • Zákazníka – toho budete pravděpodobně hrát Vy – který může:
    • Chtít vidět další města
    • Změnit svá přání

    Je už jen na týmu a jeho vyjednávacích a prezentačních schopnostech, aby zákazníka uspokojil, či mu vysvětlil, že daný požadavek na změnu nestihne.

Cílem, jak jsem psala nahoře je mít funkční produkt a spokojeného zákazníka. Hodnotí se tedy, jestli byl tým schopen dokončit úlohy v backlogu a jestli je zákazník spokojen s výsledkem.

Celkem jsme hráli na 6 Sprintů, tedy celá hra vyjde na hodinu. Před hrou budete potřebovat cca 15 minut na vysvětlení a cca 15 minut na organizaci týmu a vytvoření úvodního backlogu. Po hře cca 30 minut na prezentaci celkových výsledků jednotlivých týmů a retrospektivu.

Na závěr přikládám prezentaci ke hře. Jestli budete mít jakékoli dotazy, náměty pro zlepšení, nebo zkušenosti, dejte vědět.