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

Máte agilitu? A mohla bych ji vidět? Jak moc jsme agilní? Pomáhá nám agilita? Podobné otázky zaznívají během Agilní transformace poměrně často. Firma potřebuje vědět, jak na tom vlastně s Agilitou je, ale jak na to?

Máte agilitu? A mohla bych ji vidět?

A jak moc agilní vlastně jste/jsme?

Pomáhá nám ta vaše agilita?

Intro 

Podobné otázky mohou během Agilní transformace zaznívat poměrně běžně. Firma se rozhodla transformovat a teď by chtěla (minimálně management) vědět, jak na tom vlastně s Agilitou je.

Musíme přiznat, že i zde jsme jako Agilní koučové museli projít vývojem. Ještě před pár lety byla běžná odpověď: „Agilitu přece nemůžete měřit. To je jako byste měřili, jak moc štěstí máte nebo jak moc kvalitní je vaše manželství. To přece prostě víte. Tomu prostě musíte věřit. Agilita nám přece pomáhá k naplňování naší strategie/vize a to se buď děje nebo ne.”

Změna u které chceme sledovat návratnost

Jenže když firma investuje nemalé prostředky do toho, aby změnila styl řízení, organizační strukturu a mindset, tak je poměrně legitimním požadavkem vidět, co za to dostává zpět a jak se jí to vlastně daří.

Není snad základním principem Agilního přístupu neustále si klást otázku, zda to, co dělám, má nějakou hodnotu, případně jak ji zvýšit? A jak to tedy uděláme, když nejsme schopni určit metriku něčeho jako Agile maturity a dokonce říkáme, že ji nemá smysl hledat?

Přímé vs. nepřímé ukazatele

Na druhou stranu Agile je hlavně o změně způsobu myšlení, přístupu, proaktivitě, týmovosti a zaměření na zákazníka. A to se nedá změřit přímo a exaktně jako např. cashflow. Proto je musíme měřit nepřímo skrze jiné ukazatele. A tady je potenciální riziko, které jsme bohužel zažili v praxi mnohokrát. Platí známé “what you measure is what you get” neboli jakmile něco začnu měřit, anebo dokonce začnu na základě těchto měření odměňovat, lidé v organizaci se zaměří na nejsnadnější cestu, jak taková čísla vykázat. Ne nutně s pochopením, co bylo smyslem a cílem, který se za takovým nepřímým ukazatelem ztratí.

Zažili jsme například rozhodnutí hodnotit vývojový tým podle počtu chyb v Jiře. Což vedlo ke snížení pokrytí testy a když už se nějaké chyby objevily, vůbec se do Jiry nedostaly a chyběly tak důležité statistiky. To vedlo k problémům s chybami během nasazování a v produkci – bylo mnohem složitější je odhalit a vydat hotfix.

Dalším příkladem může být měření délky trvání Stand-upů. Je doporučeno, že Stand-up trvá cca 10 minut, tak proč nepoužít tuto metriku na měření, jak je tým v Agilitě daleko? No protože nám jde přece o přínos Stand-upů pro sladění a přehled týmu a nikoli jejich délku. V praxi jsme poměrně často viděli, jak si lidé pochvalovali krátké Stand-upy a když jsme se zeptali na jejich hodnotu, tak odpovědi byly rozpačité, vágní nebo dokonce následovalo ticho, jelikož si tuto otázku nepoložili.

Častá rovněž bývá snaha hodnotit výkonnost týmu. Zažili jsme snahy použít k tomu Velocity nebo obecně Story pointy. Vedlo to pochopitelně k podvědomému ohýbání odhadů během Groomingu, aby tým s jistotou dosáhl předem určeného cíle – dával větší odhady. Tudíž to nabouralo jakoukoliv schopnost predikce pomocí Velocity. 

Toto chování je dost podobné tomu, když se v továrně měří tzv. normy. Všichni na dílně jedou na 50% svého výkonu, aby šel normovaný čas v pohodě zvládnout, příp. překročit a všichni si tak sáhli na prémie. 

Jak na to

Navzdory rizikům a odstrašujícím příkladům z předchozího odstavce se vám pokusíme nabídnout tři cesty, jak přistoupit k měření Agile maturity. Každá má své plusy a mínusy.

1. Měření Agilní “mechaniky” – tím myslíme sledování naplňování procesní stránky některé z Agilních metod. Např. pokud si tým jako způsob práce zvolí framework SCRUM, sledujeme, zda a jakým způsobem připravuje Sprint, zda probíhají Stand-upy a zda a jakým způsobem probíhá Retrospektiva.

  • Výhoda: jednoduchost, jednoznačnost a okamžitá aplikovatelnost – tým se zaměří na provádění konkrétních kroků (“fake it till you make it”).
  • Nevýhoda: jak jsme popisovali výše, je tady vysoké riziko, že se tým bude zaměřovat na mechanické provádění aktivit, i když nebude naplňovat jejich smysl/přínos (viz příklad – délka Stand-upu); dalším nedostatek tohoto přístupu je, že se nedá aplikovat na firmu plošně, protože je svázán s konkrétní metodou, která je vhodná jen pro část firmy.

2. Feedback na naplňování principů – tento způsob odstraňuje riziko předchozího bodu tím, že se nezaměřujeme na sledování konkrétní metodiky, ale na naplňování Agilních principů tak, jak jsou popsány např. v Agilním manifestu (viz https://agilemanifesto.org/principles.html); sledujeme a hodnotíme třeba to, zda je tým na pravidelné bázi v kontaktu s reprezentantem zákazníků (typicky Product owner, business apod.). 

  • Výhoda: tato technika vede k pochopení smyslu, proč se daná metodika (např. SCRUM) nasazuje a co tím chceme získat; dá se také aplikovat na firmu plošně.
  • Nevýhoda: je to “vyšší dívčí”, která vyžaduje hlubší pochopení principů a svou obecností může vést k různým výkladům.

3. (Business) Indikátory transformace aneb proč to celé děláme? Chceme rychleji dodávat na trh? Chceme lépe odpovídat na potřeby zákazníků a mít jejich lepší hodnocení? Co je tím pravým důvodem? A ten důvod můžeme sledovat a vyhodnocovat. A to je třetí způsob, jak hodnotit úspěšnost Agilní transformace.

  • Výhoda: soustředíme se na ultimátní přínos/hodnotu, proč do transformace investujeme, což vede k soustředění se celé organizace na tento cíl (včetně hledání efektivních cest, jak tento cíl naplnit, bez ohledu na Agilitu nebo konkrétní metodu).
  • Nevýhoda: jde o tzv. “zpožděné (lagging) indikátory”, tj. pohled do zpětného zrcátka, který nám až se zpožděním říká, zda jsme dosáhli našeho cíle – po několika měsících až letech od okamžiku, kdy transformaci spouštíme; tím pádem dochází k nejednoznačnosti a možnosti zpochybňování – např. na spokojenost zákazníků může mít stejně tak dobře jako Agilní uspořádání vliv nová verze produktu s lepším UX; předchozí dva způsoby jsou naopak příkladem tzv. “leading indicators”, čili ukazatelů, které mi pomáhají předvídat, že se do cílového stavu dostanu, když dělám aktivity tady a teď.  

Jako nejlepší se nám v praxi ukázalo tyto přístupy vhodně kombinovat. Nízkoúrovňové přístupy (viz. první způsob “Mechanika”) zajistí rychlou zpětnou vazbu, na jejímž základě můžeme rychleji reagovat, hlavně na začátku transformace. Vysokoúrovňové nám pak v dlouhodobějším horizontu pohlídají naplňování smyslu.

V dalším díle se detailně podíváme na první způsob – Měření Agilní “mechaniky”.

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