Více než dva roky s přestávkami provázíme lidi z ComApu Agilní transformací. Rádi bychom vám přinesli tuto transformaci z různých úhlů pohledu, a proto jsme se rozhodli vytvořit sérii článků, ve kterých vyzpovídáme vždy jednoho člověka na klíčové pozici v této firmě.
Pokud byste se chtěli dozvědět něco více o firmě ComAp nebo jste chtěli před čtením získat balkónový pohled na celou transformaci, doporučujeme si přečíst nejprve tento článek.
Hlavním tahounem změny v ComApu byl na naší straně Honza Krchňák, kterého tentokrát vyzpovídal naš kolega Radek Gajdušek.
Honzíku, jak spolupráce s ComApem začala?
Setkali jsme se s Markem, hlavou celého vývoje. Situaci v ComApu jsme z jeho slov pochopili takto:
- V ComApu probíhá Agilní transformace.
- Mají představu co by jim to mělo přinést, ví proč by chtěli být agilnější: mají hodně projektů a roste jim to pod rukama. Těžko se jim v tom orientuje, pracují na všem a vlastně se nic nehýbe.
- Mají pár nadšenců, které to moc zajímá a pár lidí co si zašli na Agilní školení.
- Provedli změny organizační a procesní. Vývoj se rozdělil do Tribů – relativně soběstačných jednotek schopných vyvíjet a dodávat kompletní část produktu.
- K těmto jednotkám přidali lidi z Product Managementu.
- Práce se distribuovala v řetězci Product Manager – Analytik – TeamLead. TeamLead si už přáci přerozdělil ve svém týmu, případně spolupracovali v rámci širšího Tribu ve více týmech.
- A začali fungovat ve 14-denních sprintech.
Výše popsaný začátek transformace jim přinesl reálné benefity: produkťák více věděl, kdo je jeho tým, co dělají a podobně, byli v kontaktu častěji a podle potřeby do detailu. Ale reálně ani měřitelně to žádný velký benefit nebyl. Pořád vznikaly spory o tom co dělat dříve a co později, neustále byl tlak z Produktu že dodávky jsou pomalé a malé. A pořád se hledal ten, kdo za to může.
Je to typická situace se kterou se setkáváš u klientů?
Ano, toto potkáváme v transformacích často. Nejčastěji to ukazuje na tyto skryté problémy:
- Aplikace agility pouze do koncových týmů (jen Scrum pro vývojové týmy)
- Silná rozhodovací role nahoře, spousta rozhodnutí musí čekat na schválení
- Zodpovědnosti v odděleních, vznikají sila s odlišnými cíli a potřebami
- Ze Scrumu slouží pouze iterativní plánování úkolů, jako tým nehledíme moc na jejich celkový přínos/hodnotu
- Product Owner je ten, kdo vymýšlí CO budeme dělat, tým to jen přijímá
- PO a tým mají zdánlivě stejné a přitom rozdílné cíle (jeden zvýšit výdělek, druzí dodat slíbenou funkcionalitu v termínu)
- Rozdělení do tribů proběhlo pouze v IT, ne v celé organizaci
- Retrospektivy jsou využity pouze ve vývojovém týmu, tudíž dopad změn z nich je značně omezený
- Mezi produktem a vývojovým týmem zůstává mezivrstva projektů. Tato pomáhá při plánování, ale brzdí poté změny a zaměření na dodávanou hodnotu – snaží se jen splnit co bylo slíbeno a naplánováno.
- Obsah práce/úkoly pro tým zůstávají původní – analýza, odhady, návrh, implementace, ověření – přesně v této sekvenci. Tím pádem máme pouze iterovaný waterfall bez větší změny.
Tyto a další problémy jsou naprosto typické pro spoustu společností. Na jednu stranu zde Agilita/Scrum stále pomáhají, protože samotné iterativní dodávky ukazují průběh a rozkrývají problémy dříve. Nicméně zde chybí hlavní benefit Agilního přístupu – brzká identifikace hodnoty a pravidelné pře-prioritizování. Tím typicky Agilita zajišťuje největší zrychlení – hledá co NEuděláme a dává nám možnost to aktivně řídit.
Jak jsi jim konkrétně pomohl?
Použili jsme náš RainFellows framework, kterému říkáme Transformation (re)Starter Pack (TSP). Jde o sekvenci aktivit a workshopů, kterou klientům pomůžeme si:
- Ujasnit, co je ten problém co chtějí řešit a jak poznají, že je to hotovo (OKR změny)
- Rozhodnout, které části organizace se změna týká (tým, oddělení, celá firma)
- Zažít si, co je to skutečně Agilní přístup, jak se liší od jiných a co chybí právě nám
- Zažít si, co je Agilní leadership a že ke změně nestačí pouze proces, ale je potřeba se podívat i na kulturu
- Vzít ty zážitky a přetavit je s lidmi v reálnou změnu, kterou budou sami chtít tlačit dále
- Pomoci jim hands-on ji opravdu uskutečnit, změřit a vyhodnotit
- Přetavit tento přístup v nový trvalý stav a dále rozvíjet interními lidmi.
Výstupem bývá, že dotyčná oblast je pak skutečně Agilní a skutečně těží ty slibované benefity Agility – spolu se zadavateli dělají opravdu to nejdůležitější a na posunech projektů je to znát.
Většinou to samozřejmě vygeneruje další témata – a to i tady v ComApu. Jsou to však témata příjemnějšího charakteru – jak adaptovat zbytek organizace na to, že jedna oblast náhle jede výrazně svižněji, že bleskově reaguje na změny – prostě jak tento stav sladit s rigidnějšími procesy (např. tvorba roadmapy, strategie firmy, apod).
Říkáš “zažít si” – to měníš týmy za pochodu?
Ano, měníme týmy za pochodu – jen na reálných všedních situacích se ukáže, zda je změna reálná, nebo jen napsaná.
Ale ta formulace mířila na náš způsob učení. Máme skvělé výukové hry, kterými necháváme týmy si aspekty Agility opravdu zažít i se všemi problémy a výhodami. Jednak je to zábavnější (pro klienty, ale i pro nás), ale hlavně je to extrémně efektivní. I ti nejzarytější odpůrci a odmítači si prostě prožijí v bezpečném prostředí ten jiný přístup. A při dalších lekcích a workshopech už to není diskuze o mentálním kroku “kam půjdeme”, ale “kam se vrátíme” – protože už tam ve hře byli a znají to.
Mimochodem, většina firem si pak o tyto jednotlivé zážitkové akce říká dále, pro nově nastupující lidi, při přestavbě týmů, apod. Zjistili že je to skvělý způsob jak zapojit nové lidi a týmy mnohem rychleji a příjemněji.
Dobrá, takže zážitek, workshopy na rozjezd… a co pak dále?
Dále je to navazující mentoring. Tahle část se docela špatně plánuje, protože každý tým potřebuje něco jiného. S některými procházíme i základy, jako je tvorba správných požadavků a prioritizace, s některými jen ladíme detaily, typu mezi-týmová spolupráce.
Celkově se snažíme jít týmu chvíli příkladem (vedeme z pozice externího Agilního kouče) a co nejdříve to předat na interního člověka, který změnu vede dále. Tomu jsme pak k ruce a on s námi řeší další otázky a témata.
S ním a se zadavatelem pak identifikujeme další oblasti na které se zaměřit. U ComApu to bylo jednak téma Portfolio Managementu (jak adresovat práci v dáli před námi) a téma efektivity a inovací (workshop který si nazvali trefně “Dvakrát tolik za polovic”). Děláme na tato témata konkrétní problem-solving workshopy, kde problém rozebereme, popíšeme, rozmyslíme a započneme s kroky k řešení. Ty pak napojíme na běžící procesy, ať aktivita po workshopu tzv. “neumře”.
Celkově jsme pak k dispozici podle potřeb klienta – někde více, někde vůbec.
Jak hodnotíš ze svého pohledu přínos tvého působení pro ComAp?
Myslím, že se nám povedlo několik věcí:
- Pomohli jsme výraznému sblížení Produktu a Delivery, takže na cokoliv se teď dívají z pohledu “my”. Možná to tak nezní, ale je to obrovská změna, která je masivně posunula vpřed. Místo interního boje tak směřují své úsilí ven a můžou se soustředit na výzvy trhu, kterých je aktuálně dost pro všechny.
- Umožnili jsme jim hands-on mentoringem zažít si benefity Agility. Na tom projektu kde jsme byli zapojení si stakeholdeři jásali – konečně měli projekt pevně v rukou. A když přišly problémy (jak u snad každého projektu chodí), tak se mohli volně rozhodnout jak to řešit a vybrali si společně nejlepší cestu dále.
- Dlouhodobě zde působíme v pozici externí inspirace – občas se objeví problém, který nemá jasné řešení ani vlastníka. Tak jsme jim k ruce a hands-on pomůžeme to rozkrýt a přinést do toho pohled zvenku – jak něco takového řešili jinde a co o tom říká teorie. To je pro ně super v tom, že si téma nemusí nikdo dlouze studovat interně, prostě spácháme workshop a studujeme si už jen oblast konkrétního řešení.
Jak dlouho to celé trvalo a jaké je tvé dnešní zapojení v ComApu?
S ComApem už spolupracujeme přes dva roky. Zpočátku pár workshopů na rozjezd, přestávka na vyhodnocení, pak intenzivní mentoring jedné oblasti, opět nechat chvíli působit. Pak přišlo několik dalších kol workshopů pro napojená oddělení a návazné follow-upy. Aktuálně jsme ve fázi občasné konzultace, případně ad-hoc workshopu – neřešíme žádné konkrétní téma.
