Jak moc Agilní vlastně jsme? – díl 4.

V předchozích dílech (1. díl, 2.díl, 3. díl) jsme vycházeli z předpokladu, že se rozhodnete zavést Agilitu a chcete to dělat dobře – že to nechcete dělat jen “naoko” a nebo si nechcete “vzít jen to, co nám dává smysl” (jinými slovy: moc se nezměnit). Proto jsme v našich článcích popsali nejrůznější indikátory, které vám pomohou udržet se na oné cestě “dělat to dobře” a nezkřivit si zavádění Agility. Ať už z důvodu neznalosti, podlehnutí tlakům, že je to složité, neřešitelné, nebo prostě z lenosti. 

V určitý moment ale nastane chvíle, když už se o Agilitě v organizaci prvoplánově nebavíte. Buď už je všem hodnota tohoto přístupu jasná a není třeba ji zpochybňovat, nebo si na to všichni prostě zvykli. A nebo se všichni vyčerpali dlouhým procesem reorganizace, transformace. Důvody mohou být různé.

Výzvy ale zůstávají

Dynamika trhu se změnila – kombinace covidu, války na Ukrajině, nárůstu cen energií, inflace, masivního vtrhnutí tématu AI, to vše dohromady způsobilo a způsobuje nepředvídatelnost vývoje na trhu. Pak jsou tu ale také staré dobré interní faktory – mít několik (desítky, stovky, tisíce) lidí na jednom místě, znamená vždy dostatek výzev, aby se firma dokázala dostatečně zaměstnat sama sebou. 

Z našeho pohledu je posun od zavádění Agility pro Agilitu samotnou směrem ke konkrétním výzvám správným vývojem. Protože je to cesta, nikoli cíl. Proto nastává ta pravá chvíle posunout se od indikací Agility (viz předchozí články) směrem k měření, nakolik se nám podařilo nebo daří odstraňovat původní výzvy, kvůli kterým jsme vůbec o Agilitě začali uvažovat. 

Příkladem takových výzev mohou být například následující:

Tento výčet není úplný ani všeobecně platný. Jde o výzvy, které velmi často identifikujeme u našich klientů. Vy si můžete sami sepsat takový seznam TOP výzev vaší společnosti a pro ně hledat metriky.

Indikátory, jak jsme na tom

Jakmile čelíme nějaké výzvě, máme tendenci okamžitě reagovat. Což nám neřekne nic o tom, jestli a jak dobře se nám daří danou výzvu řešit. Podléháme pouze iluzi, že “pro řešení přece něco děláme”, a to nás naplňuje klidem.  

Pojďme si tedy k výzvám uvedeným výše uvést pár obvyklých možností, jak u nich sledovat posun:

Přičemž platí, že pro každou metriku je důležitý trend a čas dosažení hranice, o které víme, že má pro nás zásadní dopad (přežití, rozvoj…).

Pokud jsou pro vás relevantní výzvy ze seznamu v levém sloupci v tabulce výše a zároveň žádným způsobem neměříte jejich posun, doporučujeme inspirovat se příklady indikátorů v pravé části tabulky a začít je měřit. Samo o sobě vám to přinese velmi překvapující zjištění (“Naše aplikace je nejpomalejší na trhu”, nebo “Pokud tento člověk odejde, můžeme to zavřít. Nikdo tu nemá jeho znalosti”). Za druhé pak budete dělat kvalifikovaná rozhodnutí, jak tyto výzvy vyřešit a zda se vám to daří.

Řešení

Jeden náš klient nedávno trefně poznamenal: “Kdybych řešil každou výzvu jednotlivě, nejspíš bych se bez Agility obešel. Musím ale řešit několik výzev najednou a to pro mě znamená, že se už bez Agility neobejdu. Nebo bych tím znovu vymýšlel kolo.”

Příkladem je výzva 2. Potřebujeme neustále přemýšlet nad hodnotou pro klienta a dostat to do celého procesu.

Pokud bychom řešili pouze tento bod, asi najdeme jiné techniky a způsoby – od Product discovery až po hromadné masírování školeními, jak musíme být orientovaní na zákazníka.

Když to ale kombinujeme s bodem 1. Nejsme dostatečně pružní v reakcích na měnící se potřeby trhu, to už se tak snadno něčemu jako Agilita dá vyhnout jen stěží. Ostatně posuďte sami:

K vyřešení této výzvy je dobrým prvním krokem podívat se na váš proces od začátku do konce a identifikovat, co a proč vám prodlužuje čas dodávky a reakce na nutné změny. Typickým důvodem bývají neustálé chyby a nedorozumění mezi lidmi v různých částech procesu. Chyby, které se najdou v pozdější fázi vývoje, což je nejvíc náročné na detekci a odstranění, mají často příčinu v analýze, která trvá poměrně dlouho a stejně není “dokonalá”. Dalším příkladem typických průtahů je, když vývoj a testing mezi sebou nekomunikuje a nebo komunikuje pouze přes Jiru, protože jsou na home office. Chybu si pak všichni přehazují jako horký brambor nebo se prostě neděje nic.

Jedním z řešení je sesadit k sobě osobně lidi z businesu (poptávka), IT a Ops. Z naší zkušenosti nemusí jít o 5 dní v týdnu, ale 3 jsou kriticky nezbytné. Druhým krokem je pak rozbít velké komplexní zadání na malé dodávky, v rámci kterých nepotřebujete 100% komplexní analýzu, ale neustálou interakci mezi analytiky, zadavateli, IT, atd. Být spolu znamená, že jsou schopni najít nejefektivnější řešení. Když ten, kdo realizuje úkol, má i kontext a má u sebe někoho, kdo mu ten kontext neustále aktualizuje, předcházíme tím oné nekvalitě a zbytečnému prodlužování v pozdějších fázích procesu. Společně tak dodávají hodnotné kousky mnohem rychleji a díky tomu rychleji přichází zpětná vazba od klientů, jestli je to opravdu to, co jim dává hodnotu.

Podívejme se ještě na výzvu 6. Zavlastnění produktu společně spolu s výzvou 7. Přetížení klíčových lidí. Ty vytváří bludný kruh téměř ve všech organizacích, kde jsme byli. Skupina “superhrdinů” se účastní všech diskusí, protože mají v hlavě “komplexní matrix”, který nikdo jiný v organizaci nemá. Proto se nikdo jiný neodváží bez těchto “superhrdinů” udělat rozhodnutí a zároveň, jejich přetížení jim brání věnovat se přenášení tohoto kontextu na další lidi, aby byli více samostatní a mohli dělat rozhodnutí za sebe. Takže nováčci po chvíli odchází, nebo jsou nevytížení, protože s nimi nikdo nepracuje. Není pak nikdo, kdo by tu práci udělal. Takže jsou “superhrdinové” ještě více přetížení. Bludný kruh.

Spousta lidí v organizaci si hledí svých úkolů (“Jsem najatý jako vývojář, dejte mi jasný úkol a to je vše”). To ale nestačí. “Už dva týdny běžíme jen na jednom uzlu, tj. bez jakékoliv zálohy pro případ výpadku. Dělá s tím někdo něco? Co budeme dělat, až vznikne problém?” zazní na jedné typické schůzce. Všichni přítomní se na sebe nechápavě podívají a odpovědí je mlčení. Každý má totiž pocit, že má splněno. To ostatní je přece odpovědností Projekťáka, Delivery manažera, prostě kohokoliv, kdo je placený jako manažer.

Organizace, kde se nečeká na rozhodnutí pár přetížených jednotlivců, fungují na jiném principu. Hlavní rolí seniorů, manažerů a lídrů v takové organizaci je vytvořit podmínky a kompetence u ostatních lidí v organizaci, aby byli schopni taková rozhodnutí dělat sami. Což začíná od nastavení cílů a očekávání od těchto klíčových lidí – čekám a odměňuji, že hasili další požár? Pak se asi nic nezmění… Pokud chci vidět změnu, tak v cílech a očekáváních musí být právě výše zmíněná metrika, kolik % času věnuje dotyčný mentorování a kolik “hašení”.

Není problém zastavit celý jeden stream či část dodávky a investovat čas do rozvoje, abychom později mohli tuto investici zúročit dodávkou relevantnější hodnoty.

Zároveň celý tým je zodpovědný za kvalitu dodávky a její provoz. Pokud něco nefunguje nebo alerty detekují problém, musí se o to postarat. I v noci. Motivace na kvalitu a zodpovědnost je pak mnohem větší. Zároveň mám jasné kritérium, co znamená, že jsem svou práci udělal dobře.

Překvapivě jsme tím dospěli k samoorganizovaným týmům a principům DevOps.

Závěr

Agilita tedy není cílem, ale řešením určitých výzev v organizaci. Když si vaše TOP výzvy pojmenujete, definujete kritéria/identifikátory a poctivě hledáte řešení, která je naplňují, dojdete k podobným praktikám, jako autoři mnoha Agilních metod už před více než dvaceti lety. 

Pokud jste prošli Agilní transformací, měříte své top výzvy, a máte pocit, že vám Agilita nepomáhá, bývá to často způsobeno nesprávnou implementací klíčových principů. V tomto případě dává smysl se znovu podívat na metriky Agility, které jsme popisovali v předchozích článcích. A po nějaké době se vrátit k měření těchto výzev.

Tento přístup vám dá fakta. Když začnete měřit, můžete dělat kvalifikovaná rozhodnutí. Když se začnete zabývat výzvami komplexně, zjistíte, že Agilita vám umožní řešení těchto bodů dohromady, zatímco jiné přístupy spíše řeší jen jednotlivé výzvy izolovaně.

Přejeme vám úspěšné měření a zvládání výzev, přesně v duchu: Co měřím, to řídím. Podělte se s námi, jaké výzvy řešíte a zvládáte vy.

Autoři článku: Marek Hersan a Roman Šmiřák