SCRUM a časté problémy

Jeden z oborů, kterým se CEREBRA intenzivně věnuje, je zavádění agilních metodik k zákazníkům a s tím související revize procesů a optimalizace toho, jak se ve firmě co dělá. S tím jsou samozřejmě spojené určité těžkosti, jelikož každá změna se v zásadě setkává s komplikacemi a vlivem prostředí. Časté problémy, se kterými jsme se setkali a setkáváme při zavádění agilních metodik a procesů do firem, jsme se rozhodli popsat a zmínit v následujícím článku formou několika klíčových bodů. Seznam rozhodně není úplným výčtem ;-)

• Společný slovník - V prvé řadě je obvykle nutné ujednotit si slovník. A to znamená nejen porozumět prostředí firmy, kam se procesy a metodiky zavádí, ale také zajistit, aby společnost rozuměla termínům, které používáme. Zezačátku je třeba vysvětlit, co je daily standup, co je iterace, konfigurační management, kontinuální integrace, co znamená user story a story point. A nesmí zůstat jen u objasnění termínu, ale je třeba vyjasnit i benefit, který zavedení dané věci do praxe přinese.

• Stabilní team - Častým nešvarem ve firmách je to, že zaměstnanci jsou velmi často realokováni na jiné projekty. Samozřejmě je správné, když se pracovníci po nějaké době podívají i na jiný projekt, ať již kvůli přenosu know-how, nebo kvůli změně prostředí, nicméně situace, kdy člověk dělá v pondělí na projektu A, v úterý na B, ve středu opět na A a pak zas na B je špatná. Z více důvodů.
  Každý "context switching" ubere zhruba pracovní 20% kapacity. Prostě "přepnout mozek" na jinou práci něco stojí. Náhodné přemisťování pracovních sil také rozkolísává kapacitu teamu, což má za důsledek to, že se neplní plán a není možné vpodstatě ani plánovat, nemáte-li garantované kapacity. Pakliže se jedná o SCRUM, tak to zvyšuje rozptyl velocity, v případě KANBANu se snižuje "průtok" systémem. Realokovaní kolegové se také často nemohou účastnit důležitých schůzek (daily standup, sprint planning a review...) a ztrácí kontakt s teamem a know-how, což vede k dalším problémům a ve finále ke zdržením, která společnost stojí peníze.

• Zapojení firmy samotné - Představitelé společností (resp. stakeholdeři), kterým pomáháme, mají někdy tendenci sklouznout k představě, že "zavedeme ty metodiky a je vyřešeno". Přestanou se pak o svoje projekty zajímat průběžně s tím, že samotné metodiky a procesy vše spasí. To se ale nikdy nestane! Má to naopak často za důsledek nepříjemná překvapení při kontrole výstupů projektů po delší době. Také (vývojový) team samotný pak často vidí "že je management opustil" a necítí se zrovna komfortně.
  Je proto potřeba dbát na to, aby se např. vyšší management firmy podílel na vyvíjeném úsilí, aby byli účastni prezentacím výsledků milníku, sprintu, aby přinášeli vstupy a nápady do projektu.

• Doba "zahoření" - Výsledky nejsou vidět hned. Respektive nemusí být. A některé kladné výsledky jsou těžko měřitelné. Zavedení metodiky do společnosti, která se zatím vpodstatě nijak moc neřídila, pochopitelně vyvolá počáteční odpor, zdržení, někdy (u někoho) možná i zděšení. Průběžné výsledky (momentální objem odvedené práce) se mohou dočasně zhoršit, team bude např. za pracovní týden schopen odevzdat méně výstupů, protože se najednou konají schůzky, eviduje se práce v systému pro podporu řízení projektu, píše se dokumentace atd.
  Dlouhodobě ale změny povedou k rozvinutí mnoha pozitivních faktorů, jako např. zachovávání know-how firmy, lepší organizace práce, přehled o odvedené práci, zlepšení kvality výstupů a v neposlední řadě je zde i faktor spokojenosti zaměstnanců samotných, kteří budou mnohem raději pracovat v organizovaném a přehledném prostředí s jasně danými cíly. To vše ve finále vede k úsporám nákladů, resp. efektivnějšímu vynakládání prostředků.

• Scope creep - Tedy bobtnání objemu projektu ve smyslu: "Doděláme tam ještě tuhle maličkou funkčnost, to projekt nezdrží..." - to je také jeden z častých omylů. "Stokrát nic umořilo vola", jak praví staré přísloví. Na "jednu malou funkčnost" se nabalí další, kterou je také nutno udělat, následně při vývoji se odhalí další skryté problémy, do systému se úpravami zanesou další chybky, které je nutno pochopitelně odstranit a z úkolu "na hodinu" je ve finále práce pro celý team na týden...

• Komunikace - Klíčovým prvkem v každé společnosti je komunikace. Jak vnitrofiremní, tak i komunikace navenek směrem k zákazníkům a subdodavatelům. Se změnami procesů ve firmě je třeba také správně komunikovat jejich smysl napříč firmou, revidovat související procesy tak, aby změna v jedné části organizmu společnosti nevyvolala zahlcení a kolaps části jiné. Uvedení firmy / projektu do rytmických cyklů práce např. dle metodiky SCRUM je nutno správně podat dodavatelům, tj. "potřebujeme novou verzi subsystému každý sudý čtrtek, nikoliv nahodile", a zákazníkům, např. ve smyslu dodávek nikoliv nahodilých, nebo "on demand", ale pravidelných např. každého 30. v měsíci. (tímto se elegantně zbavíme povinnosti releasovat v únoru ;-)), ale také vlastnímu teamu, který musí např. vidět benefity pravidelných projektových schůzek a porad.

 

 

Uvedený výčet klíčových bodů a nešvarů s nimi souvisejících rozhodně není úplný. Rádi si přečteme Vaše další postřehy a připomínky třeba v diskusi na facebooku.

 

 

Chcete si vyzkoušet agilní metodiku v praxi a naučit se ji používat, popřípadě "vychytat" chyby, které možná děláte? Podívejte se na náš workshop "Simulace Scrumu s využitím LEGO". Materiály k němu si tam můžete klidně stáhnout a používat.