Category: Scrum

Vše o Scrum procesu

Retrospektiva – kolečko

Jednou z nejdůležitějších agilních praktik je retrospektiva. Cílem je zapojit tým do rozhodování o procesu, nechat je vyjádřit svůj názor, ale hlavně poslouchat se navzájem a pochopit, že ne každý se dívá na věc stejně. Retrospektivou se učíme a uvědomujeme si, co jsme dělali dobře a co ne. Ideální frekvence je po každém sprintu, aby se problémy zbytečně neprohlubovaly a tým měl pravidelnou a častou možnost zhodnotit, jak sprint probíhal z pohledu každého člena.

Jak retrospektiva vypadá? Možností je několik, ale začneme tou nejjednodušší. Tou je takzvané kolečko kdy všichni členové týmu odpoví na dvě základní otázky:

  • Co se mi líbilo, co co jsme dělali dobře a chtěli bychom v tom pokračovat
  • Co se mi nelíbilo a chtěli bychom to změnit

Nezapomeňte, že retrospektiva je o pocitech, jak jsem to viděl já, co jsem si myslel, jak jsem se cítil. Pocit je osobní, neklade si nároky na to být universální pravdou.

V dobře fungujícím týmu se vám může lehce stát, že nikdo v týmu nemá pocit žádných problémů a že tým subjektivně funguje dobře. Potom se popsaný framework rozšiřuje o další oblast:

  • Co by se mohlo vylepšit nebo zefektivnit

Ideální tým ani proces neexistuje, vždy se dá něco najít, jen je to občas těžké si uvědomit.

Začnete-li s retrospektivou, tým začne přemýšlet o věcech jinak, jednotlivý členové budou mít pocit, že má smysl promluvit a zapojit se. Přestanou být pasivními členy čekajícími na úkoly. A jste zase o krůček blíže k vysněnému ‘self-organized‘ týmu.

Extreme Scrum přednáška na Agileee

První ročník konference Agile Eastern Europe 2009 v Kievě je za námi. Agileee měla dobrou atmosféru a spoustu velmi zajímavých lidí. Mám-li vybrat top 2 přednášející, určitě by to byli J.B.Rainsberger se svojí přednáškou “An Introduction to Agile Through the Theory of Constraints” a David Hussman s přednáškou “Agile Journeys: How Did We Get Here and Where are We Going?”. Budete-li mít někde možnost si je poslechnout, určitě to stojí za to.

Moje přednáška je ke shlédnutí níže. Pojednává o speciální case study kdy byl použit Scrum v extrámním prostředí kde se projekty počítají na hodiny. Řešením specifické situace bylo nasazení Scrum metody a půldenního sprintu. Výsledky byly velmi pozitivní.

Část case study byla také publikována na konferenci SoMeT, 8th International Conference on Software Methodologies, Tools and Techniques.

Scrum process under specific extremely short conditions

View more documents from agileee.

Workshop agilního řízení a metodiky SCRUM

Ráda bych Vás pozvala na workshop agilního řízení a metodiky SCRUM. Workshop pořádáme spolu s Petrem Olmerem, pod záštitou Sun Microsystems a Agilního konsorcia. Kurz je plánován pro začátečníky a mírně pokročilé projektové manažery, produktové manažery, technické ředitele, analytiky, informační architekty a další.

Program kurzu

  • 9:00 – 10:00 Úvod, co jsou agilní metody, proč zavádět Scrum proces, základní terminologie
  • 10:00 – 10:15 Coffee break
  • 10:15 – 11:30 Sprint cyklus, plánování, odhady, ohodnocení úloh, burndowns
  • 11 :30 – 11:45 Vysvětlení Scrum hry
  • 11:45 – 12:45 Přestávka na oběd
  • 12:45 – 13:45 Scrum hra
  • 13:45 – 14:45 Retrospektiva
  • 14:45 – 15:00 Coffee break
  • 15:00 – 16:00 Agilita a psychologie

Více informací na stránkách Agilního konsorcia.

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.

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.

Vyhodnocení Sprintu

Posledním krokem Sprint cyklu je vyhodnocení výsledků. Příslušný počet bodů za dokončené úlohy se odečte z produkt backlogu a ze zbývajícího počtu bodů a rychlosti týmu se upraví očekávaný konec projektu. V ideálním případě by tým měl dokončit všechny úlohy, které v rámci plánovacího meetingu naplánoval a které se zavázal splnit. To ovšem v reálu není vždy pravidlem a obzvláště na začátku, než tým dostatečně vstřebá hodnotu bodu a naučí se plánovat, se skutečnost bude od původního záměru odlišovat. Nezapomeňte, že hlavním cílem je naučit tým dobře plánovat a odhadovat svoji práci. Takže po každém Sprintu by měl tým dostatečně dobře vidět, nakolik se od plánu odlišuje, a uvědomit si proč to je. A při příštím plánováni se případných chyb vyvarovat.

Obecně je dobré udělat krátkou prezentaci, kde se porovná plánování a výsledky jednotlivých týmů za končící Sprint. Jednou z oblíbených Agile metod vizualizace jsou Burndown grafy (o tom více v dalším příspěvku). Současně je dobré ukázat progres celého projektu a jeho milestonů, aby týmy přímo viděli, jak se projekt posouvá jako celek a jestli je na tom dobře (Critical Chain úlohy, Concerto graf). Zhodnocení sprintu může pak přímo přejít do plánovacího meetingu, kde jednotlivé týmy připraví plán na další Sprint. Tyto dílčí plánovací meetingy je lepší mít odděleně pro jednotlivé týmy, výsledné plány na nový Sprint by ale týmy měly v rychlosti prezentovat zase veřejně, aby vzniklo povědomí o tom, co dělají jednotlivé skupiny, kolik bodů plánují a jak se jim následně daří plán plnit.

Proces plánování – Sprint planning

Podíváte-li se na běžné softwarové projekty, většina z nich končí daleko po naplánovaném konci. To je samozřejmě způsobeno několika faktory. Tím kdo plán dělá, nakolik je zkušený, nakolik umí odhadnout, co všechno bude potřeba naimplementovat, nakolik je obeznámen s procesem vývoje a samozřejmě kvalitou a spolehlivostí vstupní specifikace. Zkusme ale začít u jednotlivých vývojářů. Kolik z nich umí dobře odhadnout, kdy svoji úlohu dokončí. Kolik z těch úspěšných udělá dobrý odhad high-level oblasti – Story? Kolik z nich odhadne délku celého projektu a s jakou přesností? Asi tušíte, kam mířím. Vývojáři často neodhadnou ani úlohu na týden, natož cokoliv abstraktnějšího. Sprint Backlog Vám zajistí příslušnou granularitu úloh, Sprint pre-planning nastaví priority pro jednotlivé Story a přiřadí je týmům jako vstup na Sprint planning.

Pár zásad na začátek. Tým je ten kdo plánuje konkrétní úlohy na Sprint. Tým je ten kdo je přiřazuje úlohy jednotlivým lidem. Tým je ten kdo zajišťuje změny v přiřazení lidí na úlohy. A konečně tým je ten, kdo je zodpovědný za výslednou kvalitu a dokončení včas v rámci Sprintu. Z čistě psychologického hlediska tým se tím, že plán sám vytvoří, také zaváže k jeho splnění, tedy slíbí, že ho splní. K takovému cíli je samozřejmě psychologicky více vázán než k jakémukoliv direktivnímu nařízení, které nemůže ovlivnit.

Jak probíhá samotné plánování. Tým dostane jako vstup Story z pre-planning meetingu. Každá taková Story obsahuje jednotlivé úlohy v backlogu spolu s ohodnocením. V případě že granularita není dostatečná je čistě v pravomocích týmu úlohy rozdělit tak, aby bylo možné je dokončit v rámci jednoho Sprintu a naplánovat jen to, co věří, že dokončí. Je to jednoduché, ale na začátku se to tak nemusí zdát. Po každém Sprintu by mělo proběhnout vyhodnocení plánu, realita by se neměla moc lišit. V případě že s Agile začínáte, první Sprinty pravděpodobně nebudou naplánované zrovna ideálně. Důležité ale je tým učit a dát mu zpětnou vazbu. Za cca 3 Sprinty by plán měl být už dostatečně věrohodný a kvalitní.

Proces plánování – Sprint pre-planning

Je načase trochu popsat jak probíhá podle Agile a SCRUM plánování. Produkt backlog už máme definovaný, Story či jednotlivé úlohy jsou ohodnoceny body. Před každým začátkem Sprintu sezvěte tzv. expert-tým složený z klíčových lidí. Obecně budete chtít sezvat zástupce jednotlivých týmů, někoho z managementu, hlavního architekta, zástupce zákazníka/zákazníků a to včetně interních zákazníků v rámci firmy. Interním zákazníkem je každá skupina závislá na Vašem výstupu (takže třeba nezávislá skupina zajišťující formální testování). Cílem je zastoupit všechny skupiny jakkoliv zainteresované na výsledku projektu. Ti by pak měli na pre-planning meetingu společně vybrat oblasti, na kterých budou po následující sprint týmy pracovat.

Není úkolem přidělovat jednotlivé úlohy ani konkrétním lidem ani týmům, ale předvybrat pro každý tým příslušné high-level Story. Na konci každého Sprintu se v Burndownu vyhodnotí výsledky a nedokončené úlohy se vrátí zpět to produkt Backlogu. Před začátkem nového Sprintu se svolá další pre-planning meeting a znovu určí priority pro jednotlivé týmy.

Hlavním úkolem pre-planningu je umožnit komunikaci jednotlivých zájmových skupin (zákazník, management, architekt, …), koordinovat a pokud možno uspokojit jejich rozdílné zájmy a nastavit priority práce pro týmy.