zuzi | Zuzi's Blog o Agilu a Scrumu

Scrum v extrémních podmínkách

Vraťme se k otázce pro jak velký tým a v jakých podmínkách lze Scrum proces použít. Ráda bych se podělila o svou poslední zkušenost se zaváděním Scrum procesu v té nejminimálnější představitelné podobě. Jak si poradit s krátkými projekty v řádu několika dní a týmu o velikosti jednoho člověka? První intuitivní odpověď je, že na Scrum můžete zapomenout. Všechny projekty by vlastně byly hotovy v rámci jednoho Sprintu, a tedy by to asi nemělo moc smysl. Jak ale zařídit abychom vždy přesně věděli, kde jsme a mohli rychle reagovat na třeba i drobné zpoždění a problémy? Zvlášť když zpoždění jeden den už může být pro úspěch projektu kritické.

Řešení je nasnadě. Nic nám vlastně nebrání Scrum proces použít, jen se musí vhodně upravit délka Sprintu. Prvním úkolem bylo vytvoření Backlogu. Jednotlivé úlohy, ohodnoceny body, byly rozděleny na celky v řádu pár hodin. Délku Sprintu jsme nastavili na půl dne. V takto krátce nastaveném Sprint cyklu už se nic neschová. Žádný delší oběd, ranní káva, ani problém se špatným ohodnocením úloh. Nic. Ale na druhou stranu, alespoň máte informace o tom, že projekt zítra nebude, již dnes v poledne. A tedy můžete zareagovat. Vyžádat si pomoc kolegy, zavolat zákazníkovi a domluvit si pozdější dodání. Pořád lepší než volat zpětně že jste to zase nestihli.

Takže jak to vypadá v praxi. Každý pátek se udělá plán na následující týden. V kalendáři rezervace času na jednotlivé projekty. Pro všechny týmy (i když tým o jednom člověku moc týmem není). Každý půlden se potom updatují Burndowny jednotlivých projektů, a případně kalendář, abychom věděli, proč se plán změnil. Docela hodně drsné. Ale hlavně, funguje to naprosto skvěle. Vzhledem k rychlosti výroby produktu, je to ale asi jediná možnost. Scrum meeting asi stačí jednou denně, na prodiskutování progresu a plánu na následující den.

Ještě jedna věc. Přesunuli jsme Burndowny na GoogleDocs, na změnu máme nastavené automatické emaily a tak stačí jen sledovat na mailu co se děje.

Příběh MBA

Nastal čas zase zhodnotit, co vše Vám může přinést MBA program. Business knowhow, kontakty, titul… Ale také i zajímavý pohled na změnu. Na to jak dělat prezentaci, jak přednášet. A jak ne. Doposud byli všichni lektoři ze Sheffield Hallam nudní patroni přednášející suchou teorii. SWOT, PESEL, Porter desetkrát jinak. Teoretické frameworky, jejichž použití v praxi bylo diskutabilní. Nemám jim to za zlé. Přecijen jsme na akademické půdě. Některé přinesly nové nápady a pohledy na věc, některé neuchopitelné, jiné jasné. Po roce a půl musím zhodnotit formu assignmentů jako velmi vhodnou. Critically evaluate… Nutí totiž tyto teoretické frameworky použít v praxi a zamyslet se nad jejich smyslem, což je často přínosné. Čeští lektoři naopak přináší osobní zkušenosti z praxe, takže vše tvoří konzistentní celek.

Poslední modul byl jiný. Také hýřil teorií, ale taknějak lidštěji. Donutilo mě to zamyslet se nad tím, jak se dá přednášet a co můžete lidem dát, když změníte formu prezentace. A jak moc velký je rozdíl, když čtete a neprezentujete. Představte si dvě prezentace. Jednu, kde lektorka čte (a jako Angličanka umí číst velmi rychle i v angličtině). Bez ohledu na obsah, je to zcela k ničemu. Přestanete vnímat po pár větách. Nejde to zastavit, rozlišit myšlenky, je to nekončící monotónní proud slov. Na druhé straně přednášky, kvůli kterým toto píšu. John Darwin z Sheffield Hallam University. Vynikající řečník. Začne videem o tučňácích. Příběhem, ve kterém je v pár minutách vše co potřebujete vědět o změně. Jak na ní. Co nevynechat a na co se zaměřit. Vše ve formě příběhu. Nedá se zapomenout. Zůstává někde v paměti. Doporučuji. Jmenuje se to Our Iceberg Is Melting. Je v něm vše. Vše co je třeba znát. Někdy uprostřed, kdy už jsou všichni unavení, začínal přednášku spotem Columbia Business School. How to manage… Just for fun…

Udělat z pohledu informací zajímavou přednášku, plnou teorie a dat je snažší. Ne lehké. Musíte tomu rozumět, mít dostatek znalostí. Ale udělat přednášku tak že vám informace uvíznou v paměti jen tak mimoděk, aniž byste zaznamenali, že se učíte teorii, to není jen tak. Vyprávět příběh či pohádku vyžaduje možná více invence a kreativity. A odvahy. Ale výsledek je řádově lepší. Nevím, jestli je možné každou přednášku proložit videem, vtipem, hudbou. Ale rozhodně se o to příště pokusím.

Jestli se také rádi učíte z příkladů, teorie vás nudí, připadá vám neuchopitelná a máte radši příběhy, zkusím doporučit dvě knihy, co jsem v poslední době četla. Jedna pojednává o změně tradičního pohledu na řízení fabriky. Ředitel co musí změnit styl myšlení a řízení výroby dřív, než mu fabriku zavřou. Vše se mu hroutí a on neví kam dál. Eliyahu M. Goldratt – The Goal. Vynikající kniha. Příběh co říká vše a je samozřejmě v obecné rovině přenositelný na jakoukoliv oblast.

Druhým objevem je FISH! Vypráví příběh jak změnit ”toxic energy dump” na místo, kde každý rád pracuje. Vychází z úspěšného modelu rybího trhu v Seattlu. Příběh, který musíte prožít, abyste pochopili hlavní principy FISH! Philosophy – Play, Choose Your Attitude, Make Their Day, Be There. Vše je na Vás, a je jen Vaše rozhodnutí, jak se k tomu postavíte.

Jak fungují organizace?

Narazila jsem na jeden velmi zajímavý článek který bych Vám ráda doporučila k přečtení. James G. March na jedné ze svých přednášek v Mexicu (1982) o organizacích a o tom, co je dělá funkčními uváděl velmi pěkný příklad (On Leadership: A Short Course – Google Books ). Použil příhodu s autonehodou ve Spojených Státech a různé vzorce chování kolemjdoucích v různých státech, aby Vás donutil zamyslet se nad tím, co v organizaci máte a co byste chtěli mít. Velmi zajímavé čtení, navíc doplněné anketou.

Kde byste chtěli pracovat Vy? V ‘Iowě’?

GoogleDocs, Backlog a Burndown Graf

O tom k čemu využít Burndown graf už jsme psala v minulém příspěvku. Template pro Microsoft Excel je k dispozici také. Nicméně takový Excel se špatně sdílí mezi distribuovanými týmy. Jednou z možností je použití nějakého komplexního online systému, ale to s sebou obvykle nese další výdaje na licence a často i omezení Vašeho procesu.

Dobrým řešením je použít GoogleDocs. Tady je jako public příklad, jak by mohl Burndown vypadat (http://spreadsheets.google.com/ccc?key=p8oML5C9M–uwofmhl1npew).

První list obsahuje Produkt Backlog. Každý Sprint se zaloguje kolik bodů se udělalo, a kolik ještě zbývá.

Tyto hodnoty je následně nutné přenést do oranžově orámované části. Zbytek už se dopočítá automaticky.

Velocity Graf je prvním ze série grafů. Červená oblast zobrazuje počet bodů, které by tým měl stihnout za jeden dané Sprinty. Modrá křivka odpovídá aktuálním výsledkům.

Dalším grafem je tradiční Burndown Graf, který modře zobrazuje, kolik bodů ještě zbývá, oranžově kolik se již dokončilo a červeně případné změny bodového hodnocení (viz řádky 10, 11 v Backlogu).

Poslední graf zobrazuje Burndown z pohledu očekávaného dokončení projektu. Modrá křivka zobrazuje aktuální počet bodů, co zbývá dokončit, červená je potom projekcí ukončení projektu. Obecně se dá říct, že pokud je modrá a červená křivka uvnitř oranžové a zelené oblasti, očekávaný konec projektu je stále v rámci projekt bufferu a vše je v pořádku.

Reflection meeting

Reflection meeting je další důležitou součástí Agilních metod. Vychází se z toho, že je v praxi těžké nastavit procesy napoprvé a bez dobré zpětné vazby od lidí co se jimi mají řídit. Agilní metody proto pracují v cyklu. Vždy po několika cyklech je vhodné se zastavit, poodstoupit a podívat se jestli navržený proces funguje. Není Sprint moc dlouhý/krátký? Je vždy na jeho konci co prezentovat? Jak funguje proces plánování? Je týmům jasná hodnota bodu? Atd.

Reflection meeting by mel všechny takové otázky vzít v potaz a zhodnotit situaci. Měl by být pravidelný, každé 2-3 Sprinty. Ideální je, když takový reflection meeting vede někdo zvenku, kdo má dobré zkušenosti jako coach, rozumí Scrum procesu a Agilním metodám, ale není přímo navázán na vedení projektu. Projektový vedoucí může být na meetingu, ale měl by být více jako pozorovatel. Rozhodně by neměl přebírat iniciativu a vysvětlovat proč to tak je. Cílem je nastavit dostatečně otevřené a bezpečné prostředí pro identifikaci a řešení problémů.

Dejte si pozor, aby měl každý stejný prostor promluvit a vyjádřit se k danému tématu. Vyhraďte např. každému minutu času, a dbejte na dodržení časového limitu. Meeting by měl identifikovat problémy a navrhnout možnosti řešení, ale nemusí nutně dojít k rozhodnutí. To už můžete nechat na projektových vedoucích. Rozhodně ale musíte na identifikované problémy rychle reagovat. Týmy nesmí mít pocit, že problémy jenom zametáte pod koberec. Akce musí následovat rychle. Ať už je to změna procesu či vysvětlení současného stavu.

Scrum a virtuální týmy

Máte ve Vaší firmě týmy v různých lokalitách? A dokonce v různých časových pásmech? Nebo využíváte pro práci často externisty? Dá se tedy Scrum který je přímo postavený na psychologii týmové spolupráce a kooperace, intenzivní komunikaci a sdílení informací použít v takto distribuovaném prostředí? Ano, ale přinese to s sebou spoustu obtíží, které byste nemuseli řešit v případě týmu pracujícím v jedné kanceláři.

Podle povahy distribuovanosti týmů či jednotlivců je třeba zvolit vhodnou strategii. Máte-li na každém geografickém místě alespoň minimální počet lidí, ze kterých můžete udělat separátní tým, určitě ho udělejte. Overhead spojený s organizováním více týmů které nejsou na stejném místě se tak minimalizuje. Obzvláště budou-li současně týmy v jiném časovém pásmu. Jednotlivé týmy potom žijí relativně samostatný Sprint cyklus a počet dotazů na členy jiných týmů se minimalizuje na rozumné množství. Tým si obvykle poradí sám. Jediná synchronizace, která je třeba je v rámci pre-planning meetingů, prezentací výsledků Sprintu a Customer Dema. Ty můžete dělat buď osobně, nejsou-li týmy moc daleko od sebe, nebo po telefonu. Použití nějakého systému pro online meetingy (WebEx) a webkamery komunikaci výrazně usnadní. Vedete-li takový vzdálený tým, naplánujte si pravidelné meetingy, kde prodiskutujete status, případné problémy a udržíte aktivní komunikaci. Je-li toho k diskuzi méně, meeting nemusí trvat déle než pár minut.

Není-li možné týmy separovat podle geografické lokality a projekt vyžaduje intenzivní spolupráci takto distribuovaných skupinek, nezbývá než velmi striktně nastavit formální komunikaci. Organizace pre-planning meetingu a vyhodnocení Sprintu bude samozřejmě stejná jako v předchozím případě. Navíc musíte podobným způsobem zorganizovat planning meeting. Použití WebExu a webkamery je v tom případě v podstatě nutné. To ale není vše. Online musíte udělat i každodenní Scrum meetingy. Udržet takový Scrum meeting efektivní je řádově horší než když se lidé vzájemně vidí. Ale jde to. Dalším střípkem do mozaiky bude online konference celého týmu v nějakém messenger systému (Skype). Tímto kanálem se v podstatě simuluje běžná konverzace, kdy se chcete kolegy zeptat na radu. Takové Osmotická komunikace ve stylu Web2.0. Funguje to celé velice dobře, ale asi by se taková organizace špatně stavěla z lidí, co si nikdy nezkusili pravou týmovou práci. Tedy jinými slovy dobrý a zkušený tým může takto pracovat efektivně i s malým časovým překryvem (Evropa/USA). Jednotlivce, co nejsou týmovými hráči, budete těžko v takovém prostředí učit co to je tým a jak se v něm chovat.

Posledním případem jsou externisti, pracující většinu času z domova. Obecně si myslím, že z takových externistů tým nepostavíte. Nabírala bych je na samostatnou práci, kde není potřeba časté synchronizace. Chcete-li z nějakého důvodu navenek vypadat jako že je to tým pracující podle Scrum metod (burndown na výstupu), asi je možné každému externistovi připravit plán, a na konci Sprintu kontrolovat jak na tom každý z externistů je. Z toho si složíte Burndown, a jste kompatibilní se zbytkem organizace, pracující týmově, plně podle Scrum metod. To ale používáte jen skořápku navenek, jen jednu metriku. Scrum je o spolupráci v týmu, ne o práci jednotlivců. Teoreticky by bylo možné použít principy z předchozího odstavce, ale nějak si to v praxi neumím moc představit. Asi by to přineslo příliš overheadu pro projekt managera, a nemyslím, že by to přineslo nějaký pozitivní efekt, co se produktivity týče.

Samozřejmě, možné jsou všechny kombinace výše zmíněných postupů. Mám osobní zkušenosti z organizací prvních dvou případů, a nestojí to příliš energie navíc. Obecně je dobré mít na každém geografickém místě jednu kontaktní osobu, zodpovědnou za hladkou komunikaci. Je poměrně těžké honit po telefonu člověka na druhé straně zeměkoule. Jednou ještě nedorazil, pak je na kafi, příště na meetingu. Online messenger systémy pomůžou statusem, ale možnost kontaktovat někoho na druhé straně je často k nezaplacení.

Scrum jako interní proces

Určitě jste se setkali s jistou nedůvěrou zákazníků ke Scrum procesu. Takže co s tím? Otevřete-li si knihu Art of War od vojevůdce Sun Tsu, jedna z nabízených strategií je “When you are going to attack nearby, make it look as if you are going to go a long way; when you are going to attack far away, make it look as if you are going just a short distance.” Tedy jinými slovy, proč vše zákazníkovi říkat explicitně a tím ho vyděsit? Honosné názvy, za kterými zákazník neví, co si představit moc nepomůžou, navíc při představě, že se bude pravidelně muset účastnit plánování spolu s týmem v něm nutně musí vzbudit podezření, že na něj chcete hodit Vaší práci. A demo? No ukažte mu produkt, až bude hotový, a neotravujte s nedodělky. Nemá přeci čas se Vám pravidelně věnovat tolik času. I to se Vám může stát. Takže co v takových případech dělat? Zkuste pozvolna a po malých krůčkách zákazníka naučit, v čem je Scrum pro něj výhodný. Ukažte mu, že jednotlivé kroky pro něj mají smyls. Komunikujte a naslouchejte. A hlavně, zákazník přeci nutně vědět, že to, co zcela neformálně děláte, se jmenuje Scrum.

Prvním bodem bude účast na pre-planningu. Jestli-že nejste schopni zákazníka dostat na váš pre-planning přímo, vždy máte možnost se s ním před meetingem zkontaktovat a to buď osobně, a nebo klidně i po telefonu. Dejte mu na výběr, co by on nejvíce ocenil, co by rád viděl nejdříve. Jeho přání pak následně můžete hájit na pre-planningu vy. Ušetříte tak zdánlivě jeho čas. Následně, po ukončení sprintu, zákazníkovi ukažte, co se udělalo. Zajeďte za ním, a vyžádejte si jeho zpětnou vazbu. Nedělejte příliš formální customer dema. Ty můžete udělat pro týmy navzájem, ale pro zákazníka udělejte soukromou prezentaci. Až si na vaše návštěvy zvykne, můžete ho postupně začít zapojovat. V dnešní době velice pěkně poslouží i různé internetem přenášené prezentace (WebEx), takže zákazník vlastně ani nemusí nikam cestovat a neztrácí čas.

Scrum má primární cíl pro Vás. Má Vám pomáhat jak být efektivní, jak zorganizovat tým, jak motivovat lidi. Jak úspěšně dokončit projekt. Nedílnou součástí je samozřejmě i zapojení zákazníka. Ale cest, kterými to docílíte, je mnoho. A nemusí být zdaleka přímočaré. Psychologie je nejmocnějším nástrojem.

IT Governance

IT governance je poslední dobou oblíbeným buzzword. Definice jsou obvykle nic neříkající, těžko se definuje co to vlastně je. O to více mě překvapil článek Best practices for lean development governance http://www.ibm.com/developerworks/rational/library/jun07/kroll/index.html.

V úvodu je popsán IT governance program, jehož cílem je nastavit pravidla a systém pro zodpovědnost, autoritu a komunikaci který bude podporovat klíčové hodnoty, cíle a strategii firmy. Systém musí brát v úvahu porovnání risků a zisků z investice v IT, nastavovat efektivní procesy a praktiky, definovat jasné cíle a role pro jednotlivé skupiny a lidi. Lean governance se zaměřuje na spolupráci, která sama o sobě motivuje členy týmu k lepšímu výsledku. V porovnání s tím jsou běžné IT governance přístupy (CobiT, …) málo flexibilní a neodpovídají tolik reálnému životu a praxi.

Lean governance je tedy jakousi obdobou Agilních metod, z hlavních bodů bych jmenovala adaptaci procesu, přizpůsobení HR k IT hodnotám, organizovat tým podle architektury systému, business-driven projekt a scenario-driven development, inkrementální zlepšování procesu, inkrementální vývoj.

Bohužel, pokračování tohoto článku, část dvě, která se měla zabývat procesy a metrikami a část tři, která měla popisovat role, zodpovědnosti, postupy a standarty mi nepodařilo dohledat. Škoda. Ale i tak článek doporučuji k přečtení.

Jak nejlépe sledovat aktuální stav úloh

V minulém příspěvku jsem doporučovala Excel pro vizualizaci výsledků Sprintu a zobrazení Burndown grafu, jako jednoduchou, levnou a efektivní metodu. Podobně se můžeme postavit k trackování statusu jednotlivých úloh, plánování na sprinty a sledování úloh v backlogu. Systémy navržené na Scrum proces Vám samozřejmě dají všechny informace o aktuálním stavu, plánu, atd. nicméně často je to velmi komplexní řešení, jehož filozofii musíte přizpůsobit svůj Scrum proces, alespoň do jisté míry. Každý produkt má své pro a proti, těžko vybrat ideální.

Jedním z možných řešení, které je zdarma, a je poněkud lepší než uchovávat backlog úloh a jejich status v Microsoft Excelu, je Mantis (bug tracking system). Originálně je to systém na trackování chyb, ale poměrně jednoduše jde použít na sledování statusu jednotlivých úloh, přiřazení úloh konkrétním lidem, plán. Mantis umožňuje posílat automatické notifikace emailem, nastavit různá práva, automaticky zobrazuje historii změn. Vzhledem k velmi dobrému filtrování si každý může přednastavit takové zobrazení, které vyhovuje jeho roli (vlastní úlohy, naplánované úlohy, backlog pro danou story, …).

Co je třeba udělat navíc. Pomocí Custom Fields si velice jednoduše přidáte nové položky – pro Scrum proces to bude Points (Body). V ideálním případě, bude-li se Vám chtít, jde pod seznam úloh přidat součet bodů, to už je ale nutné naprogramovat přímo ve zdrojovém kódu. Nic složitého. Nicméně i bez toho je funkcionalita dostatečná. Pro každý projekt dáte do seznamu kategorií (Categories) Sprinty. Mantis neobsahuje ve své originální podobě datum, tedy délku Sprintu si určujete sami. Asi by nebyl problém to doprogramovat, ale nám to vlastně nikdy moc nechybělo. Stavy jednotlivých úloh je zase ve zdrojáku velice snadno možné přejmenovat, aby více odpovídaly vašim zvyklostem. A můžete začít. Naplníte backlog úlohami, tým naplánuje Sprint, přiřadí úlohy jednotlivým lidem, a pak už jen každý den sledujete co se děje.

Bohužel, verze Mantisu se hodně liší, takže výše popisované změny ve zdrojovém kódu nejsou jednoduše popsatelné tak, aby se daly rovnou použít. My máme skoro na každý projekt jinou verzi Mantisu a změny děláme projektu vždy znovu na míru. A není to nijak zvlášť časově náročná aktivita.

Co se týče spojení s Burndown grafem, každý konec sprintu se udělá rychlá synchronizace. Přepíšeme, kolik bodů se z které úlohy dokončilo, které úlohy vznikly, a graf je hotový. Je to jistá část manuální práce, ale zabere pár minut. Komplexní Scrum systém to udělá za vás, ale zase třeba nebude tak jednoduchý a obecný.

Burndown graf template

Jak na Burndown? Možností je několik. Můžete začít provozovat jeden z mnoha systémů na Scrum proces a Burndown graf se vám bude zobrazovat víceméně sám od sebe, v jedné z mnoha podob. Systémy jsou komplexní, většinou placené a ne vždy plně odpovídají Scrum procesu tak, jak by se vám hodil. Flexibilita je relativně nízká, obvykle se musíte přizpůsobit vy. Za ty nejznámější vybírám ScrumWorks, ScrumDesk, Rally, Version One. Detailně se jim budu věnovat příště.

Druhou možností je, že si napíšete vlastní Burndown v Microsoft Excelu.

Já osobně tuto možnost preferuji. Za prvé, je to transparentní, přesně víte, co zobrazujete a jak, máte to pod kontrolou. Přikládám pro inspiraci svůj XLS Burndown template. Nic složitého. První sheet obsahuje kopii produkt backlogu s vyhodnocením bodů přes jednotlivé sprinty. Druhý sheet obsahuje výpočty pro grafy. Každý sprint se do něj přenesou dvě hodnoty z sheetu Backlog – Points Remaining a Velocity (Actual Points Complete). Zbytek se počítá sám. Na začátek projektu ještě musíte naplánovat rychlost týmu a buffer do kolonek – Planned Velocity a Planned New Points (Buffer). Další dvě záložky už zobrazují grafy: Project Velocity Plan a Burndown.