Agilní transformace Direct pojišťovny

Vyšší a hodnotnější dodávka. Skeptik teď namítne, že stačilo začít dělit práci na menší kusy. Jenže my jsme ji nedělili na menší úkoly — dělili jsme ji na funkční celky, které šly ihned do produkce. Každá story byla samostatně nasaditelný přírůstek hodnoty (no-estimate přístup, mapování na hodnotu), ne dílčí úkol čekající na ostatní. Nic nepřepadávalo mezi sprinty, individuální práce ustoupila týmové — a kdyby šlo jen o jiné dělení, narostl by chaos i chybovost. U nás byl pravý opak: počet chyb klesl o 50 %. Výsledkem je 2,5× více dodaných ucelených přírůstků hodnoty, ne víc dílčích lístků.

Rychlá a bezpečná cesta do produkce. Nasazovat jsme mohli kdykoli a bez výpadků (CI/CD), takže se hodnota k zákazníkovi dostávala okamžitě — ne až v dávce na konci. To nám otevřelo průběžné sbírání dat a zpětné vazby z reálného provozu: viděli jsme, jak se produkt chová a jak ho zákazníci používají, a podle toho ho rovnou upravovali. Schopnost takhle rychle reagovat na změnu není v pojišťovnictví standard — a bylo to znát i navenek: Direct byl vnímaný jako silný, efektivní partner, se kterým se externím firmám dobře a rychle spolupracovalo.

Nový produkt z 8 měsíců na 3. Celý proces tvorby nového pojistného produktu — discovery, design, vývoj i release — jsme zkrátili z historických 8–9 měsíců na 3 měsíce.

‍

Možná to znáte

Firma roste. Přibývají lidé, produkty, systémy. A někde po cestě se z pružné organizace stává organizace, kde:

• změna priority zasáhne víc týmů najednou — a nikdo neumí říct, co to bude stát a co se nestihne;
• každý řeší svůj kousek bez celkové vize, takže se staví funkce, ale nikdo nehlídá, jestli z nich vzniká hodnota;
• klient dostává nekonzistentní zážitek napříč touchpointy (web, mobilní aplikace, makléř, pobočka), protože každá aplikace si žije po svém;
• na zpětnou vazbu od byznysu a klientů nezbývá čas — tlak na další funkce nikdy nepoleví;
• spolupráce mezi týmy a s agenturami skřípá — víc se čeká a předává, než dodává;
• kvalita jde stranou, protože sotva něco dokončíte, čekají v zásobníku další dvě věci.

Pokud se v některém bodě poznáváte, nejste sami. Tohle není příběh firmy, která dělala něco špatně — je to příběh firmy, která rostla a musela najít nový způsob, jak spolu lidé pracují, aby růst unesla. A hlavně příběh o tom, jak takovou změnu provést zevnitř, postupně a beze ztráty tempa.

‍

Výchozí situace: dvě firmy v jedné

V roce 2015 bylo v Direct pojišťovně zhruba 130 lidí. Během pěti let vyrostl na dvouapůlnásobek lidí a pětinásobek obratu; o tři roky později přibyly stovky lidí a vznikala celá skupina.

Růst je skvělá zpráva. Potíž je, že organizace stavěná pro 100 lidí přestává fungovat pro 400 — a nikdo nevydá příkaz „od pondělí pracujeme jinak". Prostě to jednoho dne začne skřípat.

V Directu to skřípalo na dvou frontách. Firma fungovala ve dvou oddělených světech: procesní část (interní procesy, digitalizace), kde mezi byznysem a vývojem stáli analytici a kde feature cycle time narůstal do měsíců — a produktová část blíž ke klientovi, kde jsme začali zkoušet něco jiného: postavili jsme prvního Scrum Mastera a Product Ownera a dali byznys a vývoj na jeden ostrov, bez prostředníků.

Jinak byly analýza, vývoj i produkt oddělené disciplíny, každá se svým ředitelem. Odpovědnost za výsledek nikde nebyla jasná. Hodně se čekalo, hodně předávalo.
‍

Rozhodnutí, které určilo všechno ostatní

Neměli jsme od vedení mandát „proveďte transformaci". Přesto jsme ji udělali — a to, že jsme začali zevnitř a bez velkého rozkazu, nakonec určilo celý její průběh, výhody i jednu tvrdou lekci.

Místo překreslení organizační struktury jsme posilovali týmy, aby si samy určovaly způsob práce, a směr udávali praxí, ne tituly. V praxi to znamenalo dát týmu kolem produktu vlastního Product Ownera, odstranit prostředníky mezi byznysem a vývojem a nechat tým vlastnit celou cestu k zákazníkovi — konkrétní nástroje (maticové podporovatelství, sloučení analytiků, 50:30:20…) rozebírám dál v sekci 2023. Znělo to nenápadně. Ale tohle je přesně místo, kde většina transformací umírá, a stojí za to říct proč:

Změna „jen shora" je rychle propsaná, ale lidé jí nerozumí a nemají ji za svou. Změna „jen zdola" má energii a porozumění, ale jednoho dne narazí na strop — chybí jí mandát a krytí. Aby změna zabrala, musí se obě cesty v jednu chvíli potkat.

My začali zdola. V krizovém létě 2024 jsme na ten strop narazili. Není to slabina příběhu — je to jeho nejdůležitější lekce, a vrátím se k ní.

‍

2021–2022: Čtyři týmy, čtyři cesty, jeden zlom

Jak firma rostla, tak od CEO přišel pokyn: postavte víc týmů. Nevěděli jsme ale, kterým směrem — tušili jsme, co funguje líp, ale neměli to změřené. Tak jsme udělali rozumný kompromis: naškálovali oba přístupy zároveň na čtyři týmy a začali je porovnávat — tvrdými daty (cena předávek, čekání, cycle time, rework) i měkkými (baví lidi jejich práce?).

V jednom týmu se stal zlom. Silný Product Owner v něm skládal byznysové potřeby a nosil je technicky zdatným vývojářům. A tým pochopil zásadní věc: nemůže jen „vyšívat" do jedné aplikace. Aby klient viděl třeba své platby, musí být v klientské zóně, v mobilní aplikaci, u makléře i v interním systému — čtyři aplikace. Tým se musel naučit zasáhnout do všech. Ale byznysová znalost za tím byla pořád stejná — nemuseli se ji učit čtyřikrát.

To byl ten moment: Hodnota nejde skrze jednu aplikaci. Jde skrze end-to-end dodávku napříč firmou.

Z těch čtyř týmů „vyšel" jeden — a zbylé tři přesně ukázaly, na čem to stojí, nebo padá:

• Tým 1 — uspěl. Silný Product Owner nesl byznysovou znalost a kontext, tým se naučil dodávat end-to-end napříč aplikacemi. Tady vznikl ten klíčový poznatek o hodnotě napříč firmou.
• Tým 2 — selhal na leadershipu. Leader se stal úzkým hrdlem: tým se neposouval, neučil se a čekal na jeho rozhodnutí. Z byznysové strany přitom dostával jen příkazy a cíle bez kontextu a bez „proč". Bez vlastního prostoru a smyslu se ani schopní lidé nikam nepohnuli.
• Tým 3 — selhal na špatném uspořádání. Byl složený jen z byznysových analytiků bez vlastních vývojářů. Vývoj mu musel dodávat čtvrtý tým — a sám nedodal žádný měřitelný výsledek do produkce. Dlouho vymýšlel „dokonalé řešení", které navíc designoval na as-is stav, jaký si firma nepřála, místo aby řešil budoucí potřeby. Po letech se všechno předělalo a zdánlivě dokonalé řešení šlo do koše.
• Tým 4 — utopený v závislosti a operativě. Protože dodával vývoj týmu 3, vláčel prakticky dva backlogy. Nikdy se nesladil jako tým — lidé zůstali samostatní jednotlivci, chyběl focus a plánování, meetingy se vlekly, sprinty byly nepřehledné a storky donekonečna přepadaly z jednoho do druhého.

Pětadvacet procent úspěšnost — málo, nebo hodně? Pro nás strašně moc, protože jsme rychle a bezbolestně našli směr, a zároveň přesně viděli, čemu se vyhnout. A přišlo zadání: postavte víc takových týmů.

‍

2023: Z jednoho úspěchu - systém

Jeden fungující tým ještě není transformace. Abychom úspěch zopakovali ve velkém, museli jsme problémy pojmenovat celofiremně.

Tentokrát už jsme ale nešli bez krytí — a to je zásadní rozdíl oproti letům předtím. Ten jeden úspěšný tým totiž nebyl jen interní důkaz pro nás; byl to argument, se kterým se dalo jít za vedením. Board na jeho základě schválil koncept nového way of workingu i rozdělení firmy na value streamy a dal nám mandát rozjet ho naplno — ne jako další lokální experiment, ale jako oficiální směr, kterým se engineering i byznys vydají.

Tohle byl ten okamžik, kdy se „transformace zdola" poprvé potkala s podporou seshora. A právě proto měly následující workshopy váhu a byznys do nich šel: nešlo o můj soukromý nápad, který se snažím někomu protlačit, ale o schválené firemní rozhodnutí. Drivoval jsem to dál já — ale teď už s mandátem v zádech, ne proti proudu. Bez toho posvěcení by se to celé rozpustilo v běžné operativě.

Odpíchli jsme se od dvoudenního workshopu pro 100+ lidí a rozjeli adopci ve dvou směrech.

V engineeringu — a tohle je rada, kterou dávám každému, kdo se bojí velké reorganizace — jsme udělali zásadní kroky, aniž bychom překreslili organizační strukturu:

• Maticové podporovatelství: každý vývojář zůstal ve své technologii, ale dostal navíc příslušnost k value streamu a dva lidi, kteří mu pomáhají — technického leadera „sekerku" (rozvoj v technologii) a „kladívko" (pravá ruka Product Ownera, zodpovědnost za delivery). Konfliktu dvou šéfů jsme se vyhnuli tím, že práci jednoznačně řídí backlog.
• Sloučení analytiků do vývoje: místo týmu analýzy vznikla kompetence Low Code Development — zadání se přetavilo rovnou do funkčního řešení, ne do dokumentu k předání.
• Pravidlo 50:30:20: rámec pro práci s časem (nový vývoj / rozvoj a technický dluh / příprava). Ne bič, ale dlouhodobý průměr, který chrání kvalitu i lidi.
• Shift-left QA: kvalita jako součást týmu od začátku, ne poslední článek řetězce.

🔗 Detailní modul: Engineeringové týmy — matice, „hrabičky", self-design scaling a kompetenční model

V byznysu jsme udělali krok, který byl ve svém důsledku mnohem větší než změny v engineeringu: rozsekli jsme celou firmu na čtyři byznysové segmenty (value streamy) — likvidace, péče o klienta a dva komerční streamy. Nebylo to logické rozdělení na papíře; každý segment dostal svůj backlog, svoje cíle a svůj tým, který v něm dodával od začátku do konce. Místo desítek dílčích backlogů roztroušených po odděleních (a věčného dohadování, kdo má na koho čas) tak vznikly čtyři jasné proudy hodnoty, které šly napříč celým vertikálním řezem firmy — od byznysu přes analýzu a vývoj až po nasazení.

‍

Byznys jsme zároveň učili rozdíl mezi zadáním a potřebou. A každému vývojovému týmu se tím záběr zúžil na zvládnutelný výsek: nemusíš rozumět celé pojišťovně — ale téhle části rozumět musíš, a buď parťák byznysu. Právě těchto čtyř streamů a jejich backlogů se o rok později dotkne krizové léto 2024.

Souběžně běžela jedna z technicky nejnáročnějších věcí — přestavba core systému pojišťovny za plného provozu, iterativně místo „velkého třesku".

🔗 Detailní modul: Jak se dá přestavět jádro pojišťovny za běhu

‍

Léto 2024: Krize, která všechno prověřila

Tady příběh dostává zlom. V roce 2024 vstoupil v platnost nový zákon o povinném ručení — drasticky měnil práci se smlouvami u autopojištění, tehdy nosného produktu Directu.

Potřeba spadla do backlogů všech čtyř value streamů najednou — dotkla se likvidace, péče o klienta i obou komerčních streamů (auta řešil i B2B segment). Každý stream si vzal svůj kousek. Téma přitom formálně mělo svého ownera — stakeholdera, který s potřebou přišel a měl držet celý big picture napříč streamy. Jenže tu roli neunesl: jednotlivé úpravy byly v daných streamech pokryté, ale na celek reálně nikdo nedohlížel a všechno běželo v režimu „ono se to všude nějak udělá". Problém se vyeskaloval, až když bylo skoro pozdě, a muselo se zatáhnout za ruční brzdu. Nebylo to selhání systému, ale jednotlivce v klíčové roli.

V tu chvíli dostal nový způsob práce „za vyučenou". Skutečnou příčinou ale nebyl nový model, nýbrž to, že adopci na byznysové straně jsme nedotáhli — a to konkrétně: Product Owneři se pořád nedostali z role „zadavatele" do strategické role, prioritizace napříč streamy nebyla zažitá a klíčoví stakeholdeři z boardu nedrželi celkový obraz. Proces zdola byl hotový, ale chyběla mu protistrana shora, která by ho unesla — engineering naopak ukázal, že připravený je. Bylo to nepříjemné a osobně náročné. A byl to přesně ten strop: zdola se dá dojít daleko, ale ne donekonečna.

Co bylo dál, je nejdůležitější část — a snadno se vyloží špatně. Vzali jsme téma a během pár dní ho rozpadli story mappingem — technikou, která velkou funkční oblast rozloží na mapu konkrétních uživatelských kroků a úkolů, takže je vidět celý rozsah a nic nezapadne. (Víc o ní píšeme v článku na našem blogu.) Pak přišel ostrý řez: na pár týdnů jsme sloučili práci do jednoho společného backlogu, zkrátili sprinty na týden a celý engineering zaměřili na jediný cíl.

Na první pohled to vypadá jako obyčejná krizová taskforce — „dej všechny do latě a řiď je shora po týdnech". A ta forma opravdu byla krizové řízení. Ale to, co rozhodlo, krizové řízení nebylo:

• Lidé se přeskupili sami. Nikdo neřekl „ty děláš tohle". Podle story mappingu se engineři samoorganizovaně rozdělili do nových týmů tak, jak dávalo smysl v backlogu. To se nedá nařídit — to tým buď umí, nebo ne.
• Těžili jsme ze dvou let budování. Že se 60 lidí dokázalo za den smysluplně přeskupit a hned dodávat end-to-end, šlo jen proto, že už to nebyli úzcí specialisté čekající na zadání. Krize nevytvořila tu schopnost — jen ji zúrodnila.
• Nebyl to návrat zpátky, ale skok dopředu. Sloučený backlog byla dočasná odpověď na jedno ohraničené téma, ne nová organizace firmy. Po krizi jsme se nevrátili ke čtyřem streamům — posunuli se k produktovým týmům.

Jinými slovy: krizi neustála direktiva, ale schopnost, kterou transformace vybudovala. CxO umí dát lidi do latě. Co nařídit nejde, je aby se desítky lidí ze dne na den samy zorganizovaly kolem společného cíle a dodávaly bez čekání na zadání. Přesně to byl důkaz, že nový způsob práce funguje — ne jeho popření.

Výsledek: za čtyři týdny vše nasazené do produkce včas. Z trhu přišla zpětná vazba, že Direct patřil k nejlépe připraveným pojišťovnám na změnu zákona.

‍

2025: Produktové týmy a důkaz rychlosti

Krize paradoxně nastartovala to nejlepší. Firma viděla, že vývoj umí být rychlý, a využila příležitost: spustit úplně nový pojistný produkt (pojištění mazlíčků) s televizní kampaní na přelomu roku.

Tvorba takového produktu historicky trvala 8–9 měsíců. Měli jsme tři.

Postavili jsme jednodenní workshop nad customer journey pro 50 lidí a tvrdě řezali rozsah podle jediného kritéria: primární cíl je umět produkt prodat — všechno ostatní jde stranou. Jeden Product Owner pak držel hlavní backlog a kooperoval s ostatními; předávání běželo ze sprintu na sprint, někdy ze dne na den.

Produkt jsme doručili za tři měsíce. A vznikl vzor: virtuální produktový tým se zástupci všech dotčených týmů z organizační struktury, který společně plánuje, staví, testuje a spouští — místo aby si každé oddělení řešilo svůj kousek a pak se to „nepotkalo". Klíčový posun: priorita už nepadá paralelně do oddělení, ale do produktového týmu, který má všechny role a kompetence pohromadě.

🔗 Detailní modul: Pojištění mazlíčků: nový produkt za 3 měsíce místo 8

💡Vedlejší objev, který stojí za zmínku: rychlá cenovka na hodnotu. Tím, že jsme se naučili počítat náklad práce na úrovni hodiny a pracovat se sprint cost celého týmu (místo odhadů člověkodní jednotlivců), jsme uměli k jakémukoli záměru rychle přiřadit reálnou cenu. „Tahle featura odhadnutá na 4 sprinty znamená reálně cost 500k — fakt to chceš?" je věta, která změní rozhodování. A není to samozřejmost — řada firem se měření nákladu na dodávanou hodnotu dodnes brání. Nám to dalo byznysu konečně tvrdou zpětnou vazbu pro prioritizaci: u každé položky bylo vidět nejen „co to přinese", ale i „co to stojí".

‍

Duben 2025: Plochá struktura — když změna jen dožene realitu