Agilní transformace – jak na to správně?

Co je vlastně agilní transformace? Co si pod tím představit? Začíná to být jeden z nejskloňovanějších termínů v poslední době. Bohužel slýcháme spíše strašidelné historky, jak to kde selhalo a co vše se nepovedlo. Když se ptáme na podrobnosti, začínají se v odpovědích vyskytovat velmi obdobné vzorce. Setkáváme se až nepříjemně často s velmi nefunkčními případy pokusů o adopci agilních principů. Nejedná se výhradně o korporace, ale jsou zastoupeny velmi často. Vypadá to, že provozovat Scrum nebo nějaký obdobně agilní přístup je v daném prostředí opravdu těžké. A je to pravda. Proč tomu tak ale je? Potřebujeme vůbec agilní transformace? A co se s tím dá dělat? Čemu je dobré se vyhnout?

Simon Sinek ve své knize nabádá: Začněte s proč! To dává velká smysl i pro agilní transformace a proto jsme se tomu věnovali již v tomto článku. Stručně řečeno – doba se mění, byznys a změny jsou rychlejší a přežijí jen ti, kdo se budou schopni přizpůsobovat dostatečně rychle. Tímto směrem je agilní transformace také obvykle zaměřena – ke zkrácení vývojových cyklů, k lepší reakci na změny okolí, k doručování lepší hodnoty zákazníkům atp.

Co je to vlastně agilní organizace? Kam by měla agilní transformace směřovat?

Abych předešel nedorozumění, nevnímám agilní organizaci výhradně jako shluk čistých scrum týmů nebo něco takového. Je jasné, že v různých prostředích budou vhodná různá řešení s vyšší či nižší mírou používaných agilních prvků. Některé organizace budou i ve své „agilní formě“ nadále některé operace řešit jednoduchými procesy (recepce, úklid, účetnictví…). Zřejmě s vysokou mírou automatizace a UI (již dnes fungují různí chatboti, SW vám vygeneruje smlouvu atd.). Některé změny budou i nadále řešeny formou „klasicky“ pojímaných projektů – všude tam, kde to bude dávat smysl (stěhování v průběhu jednoho týdne, přestěhování výrobní linky, …). Viz můj článek o CYNEFIN konceptu.

Atributy agilní organizace

Na druhou stranu je ale potřeba zmínit, že agilní organizace v mém úhlu pohledu:

• je zaměřena na hodnotu dodávanou zákazníkům,
• řeší komplexní situace adekvátními přístupy (např. scrumem kombinovaným s lean startup nebo design thinking apod.),
• má co možná nejplošší organizační strukturu,
• má vhodně zformulovaný a stanovený smysl činnosti, existence, který poskytuje lidem smysl jejich konání,
• umožňuje motivaci lidí tím, že jim dává možnost autonomie, mistrovství a výše zmíněného smyslu (viz D. Pink a kniha Drive – Pohon),
• management spíše vytváří prostředí pro práci sebeorganizovaných týmů a jedinců než aby přímo velel,
• má vysokou úroveň kultury, ve které si lidé navzájem věří, jsou otevření a chyba není vnímána jako problém, ale jako příležitost se poučit.

Určitě by se našly i další charakteristiky, ale upřímně, i to uvedené už je dost ambiciózní, že?

Agilní může být jakákoliv organizace

Rozhodně nepíši pouze o firmách vyvíjejících SW. Již jsem měl možnost na vlastní oči vidět agilně orientované týmy v PR a marketingu, vývoji HW, vývoji strojů pro laserové obrábění atd. Obvykle to je vývoj něčeho nového, rozvoj stávajících služeb, rozvoj produktu atd. Což je vše ok a patří to do Cynefin komplexní domény. SCRUM guide totiž mimochodem chápe „produkt“ (okolo kterého se celý SCRUM točí) jako produkt v nejširším slova významu, poskytovanou službu anebo i management organizace jako takové.

Je jasné, že SCRUM tým je především něco jako výrobní linka, která může za vhodných podmínek velmi dobře produkovat vysokou hodnotu. Spolu s tím však musí v organizaci také fungovat procesy vývoje produktů, product design, nebo jiný vhodný proces, který bude vytvářet dobrá zadání pro dané scrum týmy. SCRUM sám o sobě tuto problematiku neřeší.

Pokud tedy máte např. webový redakční systém, na kterém funguje 150 zákazníků, lze jako váš produkt rozumět právě ten redakční systém. A k tomu už se vám může povést poskládat SCRUM tým. Stabilní vývojový tým, který bude cross-functional a self-organized. Jehož Product Backlog bude plněn jak požadavky na rozvoj systému, tak požadavky od stávajících zákazníků (a uspořádat to bude úkol pro Product ownera). Dává to zřejmě větší smysl než separátně řešit 150 různých zakázek či projektů…  a do toho se nějak snažit ještě i o rozvoj, na který ale nebude nikdy čas ;).

Nepovedené agilní transformace

Co jsem vlastně v úvodu myslel těmi strašidelnými historkami? Předně, že to na první pohled nefunguje dobře a všichni okolo jsou z toho rozmrzelí. Management, interní zákazníci i vývojáři (a v horším případě i externí zákazníci). On se ten agile tak nějak dělá, ale jaksi to není ono. Typickými problémy jsou např. situace jako:

• Vyvíjí se v cyklech – ale jen v rámci malé části organizace, která je ale stále hodně propojená se zbytkem.
• Existuje backlog produktu (dlouhý seznam položek k řešení), ze kterého tým postupně odebírá. Často se tam sbíhají požadavky z různých míst korporace a na různé produkty a projekty nebo operativní zásahy. Což mimo jiné vede i k tomu, že i když jsou týmy cross-functional, stále existuje obrovské množství vazeb na ostatní týmy.
• Jsou review, která jsou spíše demo vyvinutého kódu než demonstrace vytvořené hodnoty pro zákazníka.
• Vývojáři nikdy vlastně neviděli zákazníka a neznají ani vizi produktu – jen seznam funkcionalit, který je více či méně záhadným způsobem nějak prioritizován.
• Product owner je člověk, jehož zodpovědností je starat se o product backlog. Ale často nerozhoduje o rozpočtu a není přímo zodpovědný za byznys výlsedek produktu.
• A další – viz i náš předchozí článek o Dark Scrumu.

Poznáváte něco z toho? Je vám to povědomé? Vídáme něco z toho (nebo i vše) bohužel často (např. od účastníků našeho Agile a Scrum tréninku, nebo na různých konferencích a dalších odborných událostech).

Proč agilní transformace selhávají?

Příčiny potíží při provádění agilní transformace nejsou zřejmě jen a pouze v nedostatečném tréninku a znalostech aktérů. To je už spíše projev, důsledek. Skutečný důvod leží zřejmě hlouběji. V principech, filosofii, kultuře. Hezky je to adresováno např. i v tomto článku o pasti v kopírování Spotify „modelu“ (pozn.: Nejedná se o model ani rámec, jen o popis aktuálního stavu v jedné divizi Spotify před pár lety). Mimo jiné se tam píše, že bez Spotify kultury (založené na důvěře, inovaci, autonomii, experimentech a co nejmenší byrokracii) je pokus o nasazení tohoto „modelu“ odsouzen k zániku. Další věc je, že když jeden způsob práce dobře funguje v určitém okamžiku pro některou firmu a její kontext, vůbec to neznamená, že je vhodný pro Vás. Je v pořádku se inspirovat, ale kopírovat je v tomto případě spíše cesta do pekel.

Imunitní systém korporace

Salim Ismail to ve své knize „Exponential organizations“ nazývá reakcí imunitního systému tradičně pojaté korporace. Taková korporace je ve své podstatě primárně zaměřena na udržování stávajícího stavu, minimalizaci změn a předcházení rizik. A rázně zadusí veškeré pokusy něco měnit.

Typické je, že veškeré kroky jsou v takové korporaci zvažovány a schvalovány na mnoha úrovních a to, co již touto mašinerií prošlo, je velmi obtížné jakkoliv změnit (samozřejmě tak dochází třeba i ke stavům, že než informace doputují na příslušnou schvalovací úroveň, je situace na místě už jiná a rozhoduje se tedy o něčem, co už není aktuální… atd.). V dnešní stále se zrychlující době je to dost smrtelný koktejl… jak už vědí lidé z Nokie, Kodaku, Blockbusteru, Thomas Cook a mnoha dalších korporací.

Každopádně jsou tyto přístupy a hodnoty velmi hluboce zapsány do „DNA“ dané organizace. Jede se na efektivitu a produktivitu nevhodně nastavených procesů (nastavených pro úspěch ve 20. století… nikoliv v 21. století). Systém řízení je založen na cukru a biči, poměrně striktní hierarchii a kariérním postupu mnoha stupni této hierarchie. V extrémnějších případech lze hovořit i určité kultuře pokrytectví a „nožů do zad“ v zájmu kariérního růstu (systém se chová tak, jak je měřen). Pozornost je zaměřena na vnitřní politiku a kariérní žebříček i proto, že zákazník je něco velmi vzdáleného a imaginárního.

A teď agile…

A teď k tomu přidejte neustále se proměňující agile… (ze své podstaty se jedná o permanentní změnu). Který není o produktivitě, ale o dodávané hodnotě zákazníkovi. Který pro dobrou funkci potřebuje co možná nejplošší organizační strukturu a co nejčastější a nejtěsnější kontakt se zákazníkem. Důvěru v rámci týmu i celé organizace a vzájemný respekt. Tedy něco zcela jiného. To prostě spolu dohromady nemůže dobře fungovat a také nebude. Většinou to skončí hrou na scrum rituály, bez dopadu na chování a postoje aktérů (více i v našem dřívějším článku o Dark Scrumu).

Důsledek?

Je to trošku jako Hong Kong – bublina demokracie v totalitním režimu. To také nemůže dobře fungovat. Stejně jako agile v korporaci, která je silně hierarchická, procesní a řízená metodou cukru a biče (více zde).

Zamýšlená změna by tedy měla být systémová, komplexní, se zvážením celého kontextu (což je rozhodně v komplexní Cynefin doméně). Změnit způsob práce jednoho oddělení může být dobrý začátek, experiment, ale nebude to fungovat bez dalších návazných kroků s dopadem do celé organizace. Tedy, pokud chcete být (více) agilní… Agile v korporaci nemůže fungovat stylem „jen jedna nebo více malých částí“. Minimálně jedna velká či dostatečně oddělitelná část se musí změnit celá.

Jak tedy na agilní transformace

Existují dva základní přístupy, evoluční a revoluční. Anebo taky něco jako „spin-off“. Dnes je asi příliš brzy hodnotit, který z nich je lepší. Ono to taky v různých kontextech může být jiné. Ve všech případech ale platí, že pro takovou masivní změnu musí být dobrý a silný důvod. Takový, který udrží energii pro změnu dostatečně dlouho. Takový, který jste schopni efektivně komunikovat napříč organizací a získávat spojence. Takový, který pochopí a přijme management i všichni ostatní. Jinak skončíte někde napůl cesty ve stavech popisovaných výše.

Důvody můžou být pro různé organizace různé – rychlejší „time to market“, lepší spokojenost v týmu, vyšší hodnota produktu atp. Spojovatelem mezi řádky pak bude obvykle touha přežít a dále se rozvíjet. Protože pokud se firmě daří a roste, nebude mít nikdo pocit, že je změny potřeba. Dobrým důvodem určitě není, že ostatní to zkouší, tak to zkusíme také… takový důvod nemá dost silnou energii.

Důležité je v tomto kontextu vystihnout správný okamžik – ještě jsme na tom dobře, ale už vidíme, že to jde dolů… v tu chvíli je vhodné agilní transformaci zahájit (samozřejmě jen pokud je to ta změna, která může v dané situaci pomoct :)).

Evoluce

První ze způsobů agilní transformace spočívá v tom, že si svou změnu odpracujete. Tedy že postupně, ovšem plošně, měníte kulturu. Postupně doplňujete chybějící kompetence, měníte postoje, míru důvěry atd. Tedy, připravíte lidi na nové pojetí práce, na které posupně přecházíte a řízeně, malými krůčky k němu iterujete.

Je to samozřejmě cesta pomalejší, nicméně také s menšími okamžitými riziky. Postupně lidem ukazujete nové a nové možnosti a prostory a není to tak velký kulturní šok. Samozřejmě za předpokladu, že máte funkční vizi, kterým směrem a proč chcete jít… a také velmi dobrý důvod to udělat a také čas to udělat (viz výše).

A jak řekl již Lao-C´, Cesta tisíce mil začíná jedním krokem.

Na druhou stranu hrozí podcenění imunitní reakce tradiční korporace, která vám ten hippie experiment rychle zatrhne. Jsou bohužel nešťastné příklady velmi zajímavě vypadajících pokusů, které byly takto zaříznuty (např. zde – čtěte až do konce 😊 ).

Revoluce

Druhá cesta je o poznání radikálnější. Prostě uděláte velký třesk a přenastavíte organizační strukturu pro agilní pojetí práce. A spoléháte na to, že si to sedne a lidi se v tom naučí chodit. A pomocí retrospektiv to dostanete do rozumného stavu. Samozřejmě s podporou agilních koučů a celého týmu, který se o změnu stará (bez toho to je čirá sebevražda).

Tento přístup vychází z principu, že systém a jeho procesy do značné míry vytváří a „způsobují“ kulturu. S čímž lze celkem souhlasit (byť silně viditelné jsou spíše ty nepříliš dobré příklady).

A také to trošku evokuje problém slepice x vejce… plodí organizační struktura kulturu? Nebo kultura plodí organizační strukturu? 

Riziko imunitní reakce je zde samozřejmě nižší – nedáte tomu čas. Na druhou stranu je zřetelně vyšší riziko celkového selhání systému…

Samozřejmě je nezbytné takto změnit celou organizaci nebo její významnou, de facto samostatnou část (třeba IT v bance 😉).

Občas se při použití této strategie agilní transformace firmy dopouštějí určitého přehmatu, při kterém si vytyčí cílový stav, který pak zavedou vodopádem a mají pocit, že bude splněno. To ale nefunguje. Agilní firma formou retrospektiv vlastně neustále mění i sama sebe… takže není nic jako cílový stav. Agile nemůže být cílový stav. Je to cesta, způsob práce, který by měl pomoci dosáhnout skutečných cílů!

Spin-off

Poslední možnost je vystavět de facto novou firmu na zelené louce. Takováto nová firma (startup) může buď cílit na nové trhy nebo se i snažit „narušit“ (disrupt) byznys svého zakladatele. O což se tak jako tak snaží desítky startupů, takže lepší, když to udělá ten váš než nějaký cizí. A uchylujete se k této cestě, když uznáte stávající korporaci jako neschopnou změny, natož takto zásadní.

Klíčové je u tohoto postupu opravdové oddělení od matky. Jinak to nefunguje. Např. v roce 2007 vytvořila korporace Yahoo (kdo že? 😊) svůj interní inkubátor Brickhouse. V něm byl sestaven jeden z nejlepších vývojářských týmů tehdejší doby. Jenže… Yahoo chtělo, aby tento tým vytvářel interní řešení, místo přímého propojení na zákazníky anebo nové příležitosti a trhy.

Imunitní systém Yahoo přirozeně zareagoval na tento cizorodý objekt. Velmi brzy byly zahlazeny všechny stopy autonomie a naopak se zvedla žárlivost a odpor napříč korporací. „Proč by měli mít ty nejlepší zaměstnance?“, „Neohrožují náhodou MŮJ produkt/projekt/cokoliv?“.

V roce 2008 byl pokus Brickhouse ukončen. Imunitní systém Yahoo sice vyhrál bitvu, ale ztratil válku. Yahoo již dnes neexistuje… čímž se dostáváme zpět k důvodu, proč vyšší míru agile v korporaci zvažovat.

Co si z toho všeho vzít?

Agilní transformace by měla být řešena s rozumem, komplexně a za základě dobrého důvodu. Který se ale zřejmě dříve či později (snad ne příliš pozdě) najde.

Ne vše musí být hned řešeno Scrumem a ten samotný také vše neřeší. Pořád bude nějaká práce i v jednoduchých procesech. Některé změny bude dávat smysl pořád řešit spíše prediktivním způsobem (byť třeba s vysokým použitím agilních prvků, autonomie týmu atd.).

Manažerů jako takových bude možná potřeba o něco méně, pořád ale někdo bude muset spravovat, rozvíjet a definovat systém jako takový, pravidla hry a hřiště, na kterém budou hrát sebeorganizované týmy. Tak jako zahradník určuje základní rozvržení zahrady, kterou následně udržuje (tu přihnojí, tu něco vypleje)… bez čehož by za nějakou dobu vznikla džungle ;).