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