5 důvodů proč failují agilní transformace

Autor: David Rektorys | 31.října 2021 | 15 minut čtení

V dnešní době mnoho korporátů provádí svoje agilní transformace a staví své agilní struktury. S větším či menším úspěchem se to děje přes všechny odvětví od bankovnictví, telco, IT, energetiku, automotive a dále. U mnoha z nich se objevují společné nástrahy a pasti, do kterých firmy opakovaně padají. V rámci tohoto blogu bych chtěl nejdříve krátce vylistovat ty nejčastější důvody, proč agilní transformace failují.

Možná se ptáte, na základě čeho zde píšu o poměrně složitých organizačních a kulturních změnách velkých firem? Protože jsem si už dvěmi takovými agilními transformacemi prošel. Nejdříve v telco, kde v O2 probíhal celofiremní transformační program SOC (Simple Online Company), který měl za úkol firmu digitalizovat a přeorganizovat do efektivnější struktury. Moje druhá zkušenost vychází z Moneta Money Bank, kde jsem byl už velmi aktivním účastníkem celé agilní transformace, která bývá na českém trhu označována jako jedna z nejúspěšnějších. Troufám si říct, že k tomu vedl jeden hlavní faktor (kromě mnoha podpůrných): celá nová firemní organizační struktura se točila kolem produktově-orientovaných, cross-funkčních (neboli obsahujících všechny role/kompetence) a end-to-endových týmů. Tyto týmy vedli Product owneři, kterým se dala nejenom velká zodpovědnost, ale také na korporát nezvykle velká míra pravomocí a samostatnosti. Následně se na tyto role dosadili ti správní lidé, kteří svými povahovými vlastnostmi, zkušenostmi a kompetencemi dokázali fungovat jako „mini firma“. Takže žádné „dvojvládí“ v podobě bezzubého Product ownera, kterému sekunduje někdo z IT. Jedna hlava, která má kompletní pravomoc a zároveň permanentně hlavu na špalku.

To byl základ úspěchu Monety, ale teď už zpátky k hlavnímu tématu: 5 důvodů, proč failují agilní transformace:

Nezájem a nedůvěra ze strany managementu
Rezistence vůči změně
Neochota investovat čas, energii a peníze
Nevyhovující organizační struktura
Mylná očekávání od agile

Ještě předtím, než se pustíme do detailu jednotlivých bodů, pojďme si říct odpověď na asi nejdůležitější otázku: proč vlastně transformovat na agile?

Je to podobné jako s digitalizací: zkoušel to CEO, CTO, CIO... ale nakonec uspěl až Covid. Vznikla totiž opravdu reálná, palčivá a urgentní potřeba velké změny. A tohle je potřeba vyvolat i ve vaší organizaci, aby agilní transformace měla vůbec šanci na úspěch. Jde totiž o hodně: průzkum od McKinsey zjistil, že úspěšné agilní transformace vedou ke zvýšení operačního performance o +50% a finanční výsledky se zvedly až o +30%!

Finanční důvod je tedy poměrně jasný, ale agilní transformace s sebou nese i nefinanční benefity: zaměstnanci a manažeři, kteří pracují v agilním setupu, mají vyšší míru spokojenosti v práci. Vidí v ní větší smysl, mají větší míru loajality vůči svému zaměstnavateli a celkově podávají lepší výkony, které opět vedou ke spokojenějším zákazníkům a lepším businessovým výsledkům. Jako zaměstnavatelé či manažeři těchto lidí tak máte jednoduchou odpověď – úspěšná agilní transformace ohromně prospěje nejenom vám. A nyní se už tedy pojďme ponořit do detailu jednotlivých bodů, které bych rád rozebral.

1. Nezájem a nedůvěra ze strany managementu

Tohle je rozhodně nejčastější důvod, proč agilní transformace failují. Ve zkratce, manažerská korporátní struktura v klasickém stylu „command & control“ je vlastně konkurencí pro agile. V plně agilním prostředí jsou zaměstnanci více samostatní, dokáží se sami rozhodovat a celkově mají menší potřebu pro manažery všech úrovní. Často tak v prvotní fázi dochází k nezájmu, nedůvěře a nepochopení agilu ze strany managementu. Pojďme si tohle téma rozbít na několik use casů:

Nezájem top managementu
Tahle jedna věc často zabije úplně celou snahu o transformaci. Top management k tomu nemusí aktivně podnikat žádné kroky – bohatě stačí, když je jim to prostě jedno. Ať už přístupem „nechám si ty svoje děti hrát“, nebo obligátní „já si to pak stejně udělám po svém“, přes poměrně časté „nemám na to čas“, až jednoduše „vůbec nevím o co jde“. Ať už je to kterýkoliv důvod, bez top managementu se v takhle obrovské organizační změně prostě neobejdete. Pokuste se je nakoupit, nadchnout a vše jim vysvětlit hned na začátku. V jeden moment, dříve nebo později, je budete potřebovat mít na své straně – aby se provedly potřebné organizační změny, aby se transformace zaplatila, aby se začalo pracovat s firemní kulturou, aby se začala celá operativa firmy dělat jinak atd. Jakmile tohle podceníte, tak v nějakém momentu se nutně musí stát situace podobná tomu, když jste si jako děti hrály v obýváku na stavění pevností – také jste naivně žili v tom, že vám to rodiče dovolí navždy takto nechat.
Nedůvěra middle managementu
Když už se vám podaří přesvědčit a nakoupit top management, stále ještě nemáte vyhráno. V korporátních firmách totiž existuje ještě middle management, který může být pro vaše agilizační snahy snad ještě nebezpečnější. Jsou to totiž často takoví ti ostřílení seržanti z prvních linií, kteří svými schopnostmi či pracovitostí vyrostli z řadových zaměstnanců v teamleadery. Tihle lidé jsou účelově vycepovaní prostředím, ze kterého vzešli, kterému rozumí a umí se v něm pohybovat. Změna jim může vadit už jenom z důvodu, že nechápou, proč by si měli sami pod sebou podřezávat větev, na které sedí. Navíc mají také pocit, že oni jsou ti „manažeři specialistů“ a kdyby existovalo něco vhodného, tak by to přece oni sami věděli a už dávno implementovali. Sami tak často brání agilní transformaci svojí nedůvěrou, bez nich se však nepohnete z místa. Musíte těmto lidem vysvětlit, že se transformace neděje kvůli nim, naopak že je to prostředek k dosažení některých jejich vlastních cílů (samozřejmě musíte zjistit, jaké cíle mají). Z těchto lidí je největší šance na rekrutování „agilních šampionů“, protože mají velkou důvěru svých podřízených (a když ne důvěru, tak formální nadřízenost). Pokuste se tento zdroj potenciálních spojenců co nejvíce vytěžit a přesvědčit, že jejich dobro je v nejlepším zájmu celé firmu.
Neochota decentralizovat
Tohle je mix prvních dvou bodů. Vzhledem k tomu, že v samém jádru agilní transformace je nutnost rozmělnit strukturu pravomocí, tak tento bod je velmi nebezpečný. Jakmile se někde objeví neochota decentralizovat, tak to obvykle znamená dvě věci: rezistence vůči změně a snaha něco zamaskovat (vlastní neschopnost, případně se zjistí, že daná pozice vůbec není potřeba atd.). Zde musíte zjistit pravý důvod, proč se někdo decentralizaci brání. Často to bohužel bývá obava o vlastní pracovní místo, protože agile spoustu rolí (včetně těch manažerských) vůbec nepotřebuje. Jestliže takový případ identifikujete, často nezbývá než se s takovým člověkem rozloučit, jinak hrozí že veškerou snahu začne sabotovat.
A bonus nakonec „my nepotřebujeme změnu“
Tohle je úplně nejlepší. My prostě změnu nepotřebujeme a basta. Ačkoliv podle studie od IBM si 75% CEO po celém světě myslí, že svět po Covidu bude zásadně jiný a obsahuje mnoho neznámých, tak někdo prohlásí tenhle nesmysl. Neříkám, že vždy je řešením změna, ale stavět se k ní takto odmítavě je rozhodně důvodem pro mentální fail agilní transformace už v samotném počátku.

2. Rezistence vůči změně

Tohle je oproti předchozímu bodu poměrně přímočarý důvod, na kterém agilní transformace failují. Rezistence neboli odpor vůči změně může pocházet z různých důvodů, ale všechny mají společné jedno – strach. Ten se může projevovat různě – nízká tolerance pro chyby, inovace, experimenty, anebo prostě jen jednoduchý lidský strach, že bych mohl přijít o svoji práci (u manažerů o kontrolu nebo svoji moc).

Na tenhle bod podle mě neexistuje moc řešení. Buďto lidé ve vaší organizaci jsou otevřeni změně, anebo se změně budou bránit z různých výše zmíněných důvodů. Je velmi těžké přesvědčit člověka, že se nemusí změny bát. Principiální důvodem, proč se lidé změny bojí, je že často změna dopadne negativně. Není to o změně jako takové. Oni se prostě bojí, že teď je vlastně docela dobré a změna způsobí, že to bude horší – v různých manifestacích toho významu. Že budou mít více práce, že už nebudou v týmu se svými přátelskými kolegy, že se budou muset naučit nové věci a tak dále.

Úspěšným způsobem, jak tomuto agilnímu failu předejít, je silná, častá a upřímná komunikace. Nikdy totiž nebudete schopni zcela eliminovat obavy lidí, můžete je ale cílenou komunikací vytáhnout na denní světlo. Následně pojmenováním těchto obav lze ukázat, že nejsou zdaleka tak hrozné, jak se lidé často obávají. Že organizační změna může vést k smysluplnější práci, že daný člověk nebude muset více pracovat, ale naopak se bude moct plně specializovat ve své oblasti, která ho baví atd.

Najděte hlavní celofiremní strach a potom ho cílenými komunikacemi postupně likvidujte.

3. Neochota investovat čas, energii a peníze

Další častý důvod, proč agilní transformace failují, je čistě materiální – firma prostě a jednoduše není ochotna investovat svůj čas, energii, peníze a potažmo focus. Tímhle problémem jsou často zasaženy firmy, které fungují v nějakém rychloobrátkovém byznysu nebo mají jasně dané business performance plány, do kterých se prostě něco tak velkého a zásadního fyzicky „nevejde“. Budu zde předpokládat, že hlavním důvodem v tomhle případě není firma sama, ale její akcionáři. Budu se tedy snažit následující use casy směřovat na ně a proč si myslí, že nedává smysl investovat do agile:

Agilní transformace trvají příliš dlouho
Častou výtkou bývá, že agilní transformace trvají příliš dlouho a tudíž stojí příliš mnoho peněz. Já s tím souhlasím. Agilní transformace už z principu nemají být krásně naplánovaný GANTTův diagram, má to být spíš šoková terapie. Nikdo neříká jít do toho bez rozmyšlení a po hlavě, ale rozmáznout agilní transformaci na 3 roky s tím, že se bude „postupně transformovat celá firma“ je prostě špatně. Promyslete to, udělejte přípravu, zajistěte si všechny ostatní body z tohoto blogu a pak do toho prostě nemilosrdně řízněte. Stejně to bude „bolet“, ale je jednodušší tu pomyslnou náplast strhnout rychle. Podle mého názoru se agilní transformace pro velký korporát s několika tisíci zaměstnanci musí stihnout do roka (střední firmy do max 6 měsíců), jinak daná změna nezanechá dostatečný vliv na změnu myšlení.
Nejsou dobře komunikované ani nastaffované
Komunikace a staffing potřebných rolí na agilní transformaci bych přirovnal k výletu autem, kdy ale pasažéři neví kam se jede a auto nemá na cestu dost benzínu. To prostě nemůže dopadnout dobře. V případě komunikace hodně záleží na existující kultuře dané firmy, protože jsou organizace kde se zaměstnanci fyzicky potkávají přímo se CEO na kvartální bázi a můžou mu pokládat dotazy, zatímco jinde se z HR (které ještě supluje roli interní komunikace) pošle jeden email ročně. Přizpůsobte komunikaci danému setupu, na který jsou lidé zvyklí. Ohledně staffingu – budete nutně potřebovat nové role. Zde záleží, jaký přístup zvolíte. Jestli externí konzultanty kteří budou všechno drivovat (nedoporučuju), nebo cestu agilních koučů v kombinaci s interními agilními šampiony (naopak velmi doporučuju).
Nenašli se vnitřní agilní šampioni
Několikrát jsem zmiňoval agilní šampiony. Co to je přesně za lidi a kde se vezmou? Nebojte, nejde o nově vytvořené pracovní místo. Naopak tohle jsou lidi, kteří pro vás už nějakou dobu pracují, jsou vám relativně loajální, mají zájem o změnu prostředí nebo nějaký další subjektivní důvod, proč se stanou těmito šampiony změny. Ještě jeden aspekt je u agilních šampionů klíčový – mají velkou neformální moc, důvěru, respekt, charisma nebo uznání zbytku firmy. Určitě takové lidi máte i u vás ve firmě, typicky to je „Jana ze třetího patra, okolo které se chodí po špičkách“, anebo „Marcelka co tady pracuje už 20 let a zná firmu od sklepa až po strop“, případně třeba taky „Honza je tahoun bez kterého se rozpadne zbytek klíčového týmu a lidi půjdou za ním i třeba do jiné firmy“. Tak pro tyhle lidi udělejte první poslední, abyste je získali na svou stranu. Bez nich se to bude dělat o dost složitěji a naopak když tihle lidé řeknou svoje pozitivní „krleš“ směrem k agilní transformaci, tak se vám najednou půlka věcí bude zdánlivě dařit sama od sebe. Pořád jsou lidé totiž „kmenového společenství“ a když kmenový vůdce rozhodne, tak lidi za ním půjdou i bez prezentací, nových kanceláří a dalších prkotin.
Snaha okopírovat ostatní místo nalezení vlastní cesty
Velmi smutný je use case, kde se agilní transformaci prostě někdo jenom snaží okopírovat od jiné, známé firmy (viz častý use case „pojďme to udělat podle Spotify modelu“, ačkoliv sám Spotify od svého vlastního modelu už dávno odešel), nebo dokonce úplně blbý use case, kdy to okopírujeme od konkurence. Když dva dělají totéž, není to totéž.
Projektově nebo dokonce finančně řízená transformace
Trochu etalon českých agilních transformací. Z nějakého důvodu někomu přijde, že je dobrý nápad agilní transformaci řídit projektově, nebo dokonce finančně. Tohle musí nutně skončit katastrofou. Jestliže vám opravdu jde o kulturní a mindsetovou změnu, tak to prostě nemůžete dělat starým způsobem. To je asi jako když chcete mít za ženu blondýnku, ale stále chodíte na rande s brunetkami. Přestaňte se držet starých cest, způsobů a návyků – přijměte nové. Asi se teď ptáte jaké? Je to úplně jednoduché – postavte firmu produktově a prozákaznicky orientovanou. A teď nemyslím v prezentacích, ale doopravdy. Vykašlete se na nějaká polovičatá řešení typu „budeme mít dva lídry tribu (business a IT) a ti se vždy dohodnou“. Prostě jedna hlava, jedna role a jeden člověk. Ve venture capital odvětví na to mají krásné rčení: „ideální počet zakladatelů startupu je lichý a tři už jsou moc“. Stejné je to s Product ownery a Tribe leady.
A jak teda postavit firmu produktově a prozákaznicky orientovanou? Jednoduše, postavte firmu kolem produktů (ne propozic ani segmentů), dejte klíčovým lidem totální pravomoc/svobodu (a zároveň plnou zodpovědnost) a nahraďte KPI za OKR včetně zákaznické spokojenosti, kterou musíte začít pečlivě měřit, vyhodnocovat, komunikovat a feedback od zákazníků brát jako hlavní vstup/input pro vaše produktové týmy. Funguje to vlastně jako nekonečná smyčka – produktový tým launchuje MVP svého produktu, získá zpětnou vazbu, udělá první iteraci, spustí, zase získá feedback, zase iteruje a tak dále. Tímhle nastavením naučíte své lidi performovat jenom na tom, co má smysl. A víte co má smysl? Překvapivě co chce zákazník, ne nějaký interní stakeholder, co si od stolu vymýšlí požadavky všeho druhu.

4. Nevyhovující organizační struktura

Tohle je můj osobní oblíbený důvod, proč se z agilní transformace často stane buřtguláš. Je to totiž ten nejvíce zbytečný a potažmo z pohledu organizačního setupu firmy také nejvíce přímočarý a jednoduchý. Jste totiž v bodě, kdy mentálně jste správně nastaveni, všichni chtějí aby se agilní transformace provedla úspěšně a už potažmo „jenom“ stačí vymyslet správnou, efektivní a vyhovující novou organizační strukturu firmy. Místo toho se často udělá série přešlapů, jako jsou následující body:

Agilní transformace provede pouze jedna část organizace (často IT)
Tohle je evergreen hlavně korporátních firem, které jsou historicky rozdělené na něco jako komerční/business divize, provozní divize, supportní divize (HR, legal atd.) a právě IT divize. V tomhle setupu se často řekne, že je potřeba provést agilní transformaci (například z úst CEO), tak se stanou následující věci: šéf businessu řekne, že agile je věcí IT a oni potřebují hlavně prodávat. Provoz řekne, že už v agilu dávno jede (ačkoliv to není pravda). Supportní divize ani neví, o čem je řeč a tak to právě celé skončí na tom, že se jde transformovat jenom IT. Výsledkem je totální bullshit, kde seniorního vývojáře tlačí do role product ownera, hrají si na nějakou formu cross-funkčnosti (ačkoliv jim chybí půlka rolí a svého zákazníka neviděli ani z rychlíku), práci si místo Wordu/Excelu organizují v Jiře a celému tomu nesmyslu nasadí korunu marketing, který s velkou pompézností na sociálních sítích prohlašuje, jak jsou agilní. Jednoduše řečeno, agilní transformace nemůže být pouze na divizní úrovni, ale musí zasahovat do všech sfér celé firmy. Hlavně z toho důvodu, že zákazníka vůbec nezajímá, která část firmy je a není agilní, on prostě chce výsledek jako celek. A když se ztransformuje pouze IT, zatímco ostatní části firmy jedou těžký waterfall a dál na vývojáře posílají zadání v podobě mnohastránkových BR (business requirements), tak se celá snaha o agilní transformaci může za stálého míchání s klidem lít do záchodu.
Transformaci provádí nevhodná osoba/role (například konzultantské firmy)
Tenhle přešlap je prapůvodně zamýšlený dobře – „pojďme si pozvat někoho, kdo ví jak na to, aby nám s tím poradil a nedělali jsme zbytečné chyby“. A pak se tenhle dobrý úmysl vezme a vyskládá se s ním cesta přímo do pekla, protože dalším krokem často bývá, že se najmou například konzultantské firmy a těm se předá veškerá zodpovědnost spojená s agilní transformací. Firma si tak nad celou snahou umyje ruce a je vymalováno. Do firmy naběhnou kočovní nájemní nájezdníci v podobě konzultantů, kteří podle svých tabulek, grafů, analýz a „best practice“ návodů začnou překopávat celou firmu. Nulové pochopení firmy jako takové, jak funguje, jakou má kulturu, byznysmodel a co chtějí zákazníci. Zákazníka tenhle proces často nevidí ani z rychlíku, objevuje se občas jenom v perfektně vyladěných prezentacích, ale jeho opravdové potřeby zůstávají nevyslyšené. Následně se často udělá „transformační program“, kde se agilní transformace naplánuje do sebemenšího uprdnutí v obřím waterfallovém GANTT diagramu, což už samo o sobě popírá organičnost agilu. Z celého krásného procesu „osvěty“ a renesance se tak stane dogmatický a nelidsky chladný humus osekaný až na kost (protože samozřejmě konzultační nájezdníci fungují stylem „fixed price fixed time“).
Tenhle přístup obvykle vede k neskutečnému vyděšení, okamžitému „boji o koryta“ a zabetonování všech přístupových cest, vedoucí ke spolupráci mezi lidmi a týmy. Všichni si před nájezdníky začnou bránit svá malá království a snaha o otevřenou firemní kulturu se utopila v bezohledném sprintu za efektivitou. Na tenhle bod nejde nic moc dalšího napsat, pokud už si vezmete na pomoc konzultanty, tak je prosímvás nenechávejte všechno rozhodnout. Převezměte aspoň trochu zodpovědnosti za proces, který je pravděpodobně největší změnou vaší firmy od svého založení.
Jedná se pouze o dílčí změny
Tohle je oblíbený fail ve firmách, kde se jede hodně na procesy a efektivitu. Agilní transformace zde proběhne pouze v jakémsi „pilotu“, nebo dokonce pouze jako procesní, operativní a organizační změna. Zcela zde chybí mentální změna a orientace na zákazníka. Kdepak, prostě jsme udělali iterativní každoměsíční releasy, naše týmy teď dodávají inkrementálně (ať už to znamená cokoliv) a basta. Když se někdo ozve, že by chtěl mít svoje vlastní DevOps release, tak je utlučen do země procesní příručkou. Nikdo se nenamáhá zapojit mozek, prostě úkol zněl jasně – dvě dávky agilu. Výsledkem je pahýl netušených možností, které by přineslo to, kdyby se lidem dala svoboda přijít s více než dalšími stránkami manuálu, více slidy v prezentacích a novým intranetem (ano, tohle je konkrétní příklad implementace agilu v jedné větší firmě).
Nejsou vytvořené end-to-end a cross-funkční týmy s pravomocí měnit věci a jasnou oblastí zodpovědnosti
Tohle je můj svatý grál. Jestli si z celého blogu neodnesete nic jiného, tak tohle si prosím zapamatujte. Jestliže si dáte něco za hlavní, neodmyslitelný cíl vaší agilní transformace, tak to musí být, že vytvoříte zcela nový typ organizační jednotky: agilní squad. Co to je? Jedná se o cross-funkční (obsahují všechny role, kompetence, dovednosti a lidi, které potřebují ke své práci) a end-to-endové (zodpovědné za celý životní cyklus daného produktu) týmy, které mají pravomoc měnit věci a mají jasně definovaný scope (oblast zodpovědnosti). Tohle je strašně důležité. Bez tohohle jednoho aspektu můžete na zákazníka myslet i třeba ve spánku, ale bez tohohle organizačního setupu se prostě neobejdete.
Tohle vám umožní vyřešit ohromné množství problémů, odbourat spoustu příčin dalších problémů a nastavit prostředí, ve kterém lidé chtějí pracovat. Ve kterém se vyvyšuje osobní zodpovědnost, inteligence a performance. Ve které se kombinuje businessová liščí chytrost a věci vymýšlet, technická hardskillová dovednost věci stavět, procesní/operativní flexibilnost okamžitě reagovat na nastalé situace. Dává to lidi dohromady, boří to klasické korporátní bariéry „my versus oni“, aneb business si zase vymyslel úplnou kravinu a vývojáři jsou introvertní omezenci bez špetky kreativity. Najednou se produktový manažer od svého kolegy vývojáře dozví, jaké jsou technické možnosti a omezení jeho návrhu nové produktové propozice, naopak vývojář má vhled a pochopení zákazníka, pro kterého píše svůj kód a vyvíjí funkcionality. Nakonec tyto týmy „vede“ role product ownera, který má důvěru managementu dělat rozhodnutí bez nutnosti schválit každý pšouk a je mu svěřený celý produkt. Pokud chcete, aby se vám agilní transformace povedla, tenhle krok zajistí třeba půlku celého úspěchu.

5. Mylná očekávání od agile

Poslední oblast, kvůli které firmy často failují, jsou mylná očekávání. Zase to rozeberu v několika konkrétních use casech:

Agile bude levnější nebo rychlejší
Další evergreen agilních transformací. Manažeři si často mylně myslí, že agile bude levnější nebo rychlejší. To je jako ten starý vtípek, že projektový manažer je člověk, který věří, že když 1 žena porodí za 9 měsíců, tak 9 žen to zvládne již za měsíc. Tenhle mýtus „agile je levnější“ s radostí rozbiju – realita je totiž často taková, že agile naopak navýší výdaje na více lidí, rolí a specializací právě kvůli tomu, že potřebujete zajistit daný end-to-end přístup. Čili nebude například jeden pool IT architektů/Solution designerů, ze kterého si týmy musí dopředu alokovat nějakou kapacitu, ale všechny týmy mají svého člověka. To samé platí u mnoha dalších rolí. Chcete mít samostatně operující týmy? Tak ony potřebují tyto role, jinak jsou bezzubé.
To samé platí i o „rychlejších dodávkách“. Často se nad tím totiž bohužel stále přemýšlí jako nad projekty, neboli něčím co má jasně definovaný začátek a konec. Tohle ale v agilu neexistuje. Agilní tým z principu jede inkrementálně, kdy dodává postupně. Není nijak definovaný konec ani to nikoho nezajímá. Důležité je, že dělá od nejvíce prioritního/hodnotného pro zákazníka. Takže myšlenka, že když něco budu dělat agilně, tak mi to ten tým dodá rychleji, je naprosto mylná a spíš ukazuje, že daný člověk vůbec nepochopil, o čem celý agile je.
Agile nám zajistí novou/lepší firemní kulturu
Agilní transformace je především radikální změna firemní kultury a přemýšlení. Organizace se silným „command & control“ stylem řízení to tak často přehlédnou jako důležitou výzvu. Snaží se tak napasovat agile do jejich organizační kultury s myšlenkou, že nám to „zevnitř přinese hodnotu“. Opak je ale často pravdou. Spíše to přinese vnitrofiremní válčení mezi odděleními/divizemi. Ve zkratce se dá říct, že jestliže nyní máte shit firemní kulturu, tak po agilní transformaci se tohle nezmění. Zapracujte na tom, jaké máte hodnoty uvnitř firmy a podle kterých osobnostních rysů se firma řídí. Teď nemyslím v prezentacích, na chodbách, ve výtahu a na záchodcích. Mám na mysli, jaké jsou dominantní osobnostní rysy vaší organizace? Je to bezohlednost, kdy manažer jde přes mrtvoly jenom aby dodal, protože se bojí boardu? Nebo je to vyčůranost, politikaření a kuloární šíření pomluv? Nebo máte férové šéfy, loajální zaměstnance, performující specialisty, motivované prodejce a board s realistickými očekáváními?
Celkové nepochopení toho, o čem vlastně agile doopravdy je
Tenhle bod je hodně palčivý už jenom kvůli vysoké četnosti Dunning-Kruger efektu v korporátech. Jde o to, že neznalost opravdového agilu korporátním harcovníkům zabraňuje uvědomit si, že tomu nerozumí. Kdyby si to uvědomili, přestali by mít nesmyslné očekávání, celkové nepochopení agilu jako mindsetu a začali by „otevírat oči“. Tohle je sice hodně teoretické, ale zároveň to dost vysvětluje situaci do které dojde spousta firem – provede se agilní transformace a ejhle, ono to pořád nefunguje. V čem byla chyba? Jednoduše řečeno jde o to, že není žádný alignment a shoda v aspiracích, touhách a hodnotách mezi lídry dané organizace. Prostě Franta si myslí tohle a Pepa zase něco jiného. Oba žijí ve svém mikrosvětě a díky Dunning-Kruger efektu neví, že neví. Výsledkem je promarněná snaha v situaci, kdy se to mohlo povést.
Pojďme si tedy naopak krátce říct, jaká jsou realistická očekávání a správné pochopení agilu: ve zkratce agile je nejlepší v komplexních situacích, kdy je mnoho neznámých, vysoké riziko a mnoho proměnných. Agile totiž svým přístupem poskytuje jakýsi mechanismus, kterým snižuje pravděpodobnost neúspěchu a zmenšuje případný negativní dopad. Dělá to již pomocí zmíněné iterativnosti, orientaci na zákazníka (focus na zákaznický feedback), přijetí osobní pravomoce/zodpovědnosti, celkové transparentnosti a ochoty experimentovat a neustále vše vyhodnocovat, zlepšovat a flexibilně reagovat na danou situaci. Pokud ve své organizaci umožníte vše výše popsané, máte velkou šanci nejenom na úspěšnou agilní transformaci, ale hlavně na lépe fungující byznys. A o tom to přece je.

Závěr

Nyní rozumíte, proč firmy stále padají do stejných pastí a dělají stejné chyby. Pokud se jim vyhnete, je velká šance, že právě ta vaše agilní transformace dopadne dobře. Budu vám k tomu držet palce a pokud byste chtěli něco zkonzultovat nebo se jen zeptat, klidně mi napište email na david@rektorys.com a já vám rád poradím 😊