Case-study: pojišťovna Direct, první Agilní pojišťovna v Čechách

Potřeba rychle reagovat na změny v silně konkurenčním trhu vedla pojišťovnu Direct k zásadnímu rozhodnutí, provést transformaci firmy na moderní Agilní pojišťovnu. Přestože tento transformační proces nebyl nijak snadný, Agilní transformace přinesla vyšší kvalitu produktů, kratší time to market a významně posílila inovace.

Úvod

Na začátek je nutné poznamenat, že případová studie se týká původní Direct pojišťovny a se současnou nemá nic společného. Každopádně si myslíme, že je velmi přínosná a stále inspirativní. Direct pojišťovna vznikla jako “start-up” se zázemím mezinárodní pojišťovny DIFI, ke které se posléze přidala britská skupina RSA.

Direct zahájila svůj provoz v roce 2007 a za prvních pět let na trhu stala nejinovativnější pojišťovnou v České republice.

Původní Direct pojišťovna byla první pojišťovna v ČR, která se rozhodla nabízet svoje produkty pouze přímo a navíc na velmi konkurenčním trhu, což vyvolávalo tlak na velmi rychlou implementaci změn v IT. Stávající waterfallový proces agilitu a time to market neumožňoval, přestože business po rychlých dodávkách volal.

Tato studie se zabývá tím, jak Direct pojišťovna přistoupila k Agilní transformaci ve větší škále, jak se pro Scrum rozhodla a jaké benefity získala jeho implementací.

"Scrum Directu pomohl stát se nejinovativnější pojišťovnou v České republice."

Výchozí situace

Málokterá organizace má pro rozjezd ideální technické podmínky a Direct nebyl výjimkou. Výchozí situaci můžeme popsat následovně:

• Legacy kód v Javě a Oracle (1,5 mil. LOC)
• Specifický vlastní jazyk používaný k nastavení systému
• Oddělení business analytiků tvořících zadání
• Oddělení IT implementující zadání
• 5 týmů na 3 geo lokacích
• Více než 50% kapacity věnováno chodu systému
• Interní a zároveň dodavatelský vývoj
• Time to market 6 měsíců a více

Rozhodnutí pro Scrum

Strategická rozhodnutí

Předpokladem pro úspěšnou implementaci v případě Directu byla správná strategická rozhodnutí, která předcházela nasazení Scrumu a byla řešena v předstihu.

1. Převzetí provozu interního informačního systému pod vlastní kontrolou
2. Soustředění vývoje IS pod jednotnou kontrolu (to nevylučovalo dodavatele a bodyshopping)
3. Odvaha udělat zásadní technologické změny (přepis části IS, webové prodejní aplikace)

Řízení očekávání

Zásadní náročnosti si vyžádala příprava na zavedení Scrumu na úrovni vrcholového managementu. Implementaci Agile & Scrumu předcházelo několik setkání a diskusí s Agilním koučem kde byla diskutována cesta, jak Scrum zavést. Bylo rozhodnuto, že půjdeme cestou pilotního týmu a následného přidání ostatních.

Pro odsouhlasení startu transformace bylo zapotřebí souhlasu Boardu společnosti. Po interním rozhodnutí IT oddělení a komunikaci s klíčovými stakeholdery proběhla prezentace Boardu, byl start odsouhlasen včetně jasných nákladů (nejen finančních) a možných rizik spojených s transformací.

Cíle

Jako důležité se ukázalo stanovení jasných a transparentních cílů transformace:

• Snížit počet produkčních chyb o 50% do 6 měsíců
• Zkrátit potřebný čas na spuštění projektu o 50% (tj 2-3 měsíce) do 3 měsíců
• Zlepšit zapojení vývojářského týmu do businessu
• Zlepšit rozložení znalostí ve vývojářském týmu, tj. že jednotlivci budou umět dělat změny ve více komponentách informačního systému
• Aby to tým bavilo

Příprava na implementaci Scrumu

Příprava byla pojata velmi pečlivě s důrazem na pochopení cílů a samotného Scrum procesu. Příprava se skládala z následujících činností:

• Externí školení pro celý IS tým a spolupracující business týmy
• Externí podporu Coache při školení a transformaci
• Přesné zmapování toku práce
• Vyjasnění očekávání s kolegy z business jednotek (kéž by existoval v té době CAL)
• Plán implementace, sdílený napříč firmou
• Plán komunikace transformace

Harmonogram transformace

• 4/2011 - strategické schválení Boardem pojišťovny
• 5/2011 - první prezentace Scrumu celému IS týmu
• 5/2011 - intensivní školení IS týmu a businessu
• 5/2011 - sestavení pilotního týmu
• 6/2011 - intensivní školení a coaching Product Ownerů
• 6-7/2011 - start pilotního týmu
• 8/2011 - vyhodnocení po 5 sprintech (čtrnácti-denní sprint)
• 8/2011 - představení nové organizační struktury IS týmu a Product Ownerů

Backlogy a týmy

Při sestavování týmu byly brány v potaz osobní preference jednotlivých členů a zároveň v týmu musí být potřebné dovednosti pro doručení User Story.

• 3 týmy po pěti až šesti členech
• 3 Scrum Masteři
• 2 architekti (Front-end a Back-end)
• 1 liniový manažer
• Týmy jsou nezávislé, nesdílí žádnou kapacitu
• Týmy ze začátku komponetové s přesahy s tím, že směřují k Feature týmům (dle LeSS)
• Každý tým se stará o:
  • projekty
  • malé změny
  • produkční podporu

"Prvním úkolem týmů bylo: sejděte se, připravte si Board a naplánujte si první Sprint."

Problémy a řešení

Problém: Jiný tým má výborné User Story a my ne…
Řešení: Coaching Product Ownera, účast zástupců týmu na refinementu týmu, kde to funguje.

Problém: Jiný tým nepracoval na aplikační podpoře, proto stihli dodat …
Řešení: Lepší plánování, spolupráce na rozdělování produkčních problémů mezi týmy.

Problém: Nemůžeme začít dělat Scrum dřív než … (bude CI, připíšeme systém, …)
Řešení: Pojďme to prostě zkusit…

Problém: Scrum je dobrý na vývoj a ne na produkční podporu
Řešení: Krátkodobě zavedení produkčních “bufferů” do sprintu, dlouhodobě dodávat v podstatě bez chyb. Zaměřme se na kvalitu!

Problém: Kdo mi teď podepíše dovolenou?
Řešení: Explicitní vyjasnění rolí, zejména liniových. V tomto případě je jednalo o team leadera, který po změně zodpovídal za technický coaching, osobní rozvoj a stanovení a vyhodnocení rozvojových cílů.

Problém: Co vlastně dělá architekt?
Řešení: Pomáhá navrhovat a oponovat efektivní technické řešení, dělá code review a podporu technickou vizi.

Koordinace mezi týmy

Scrum eventy a artefakty byly empiricky v průběhu transformace rozšířeny o následující:

• Dva mezi-týmové meetingy týdně zaměřené na plnění SLA a produkční podporu
• Produkční podpora řízena Kanbanem
• Jeden mezi-týmový meeting za sprint zaměřen na nový vývoj, takový LeSS Planning I.
• Měsíční celofiremní prioritizace se společným backlogem
• Jednotný release plán komunikovaný celofiremně
• Plánování na firemní úrovni v man-days, projekty s variabilním “scopem”
• Vzájemné týmové návštěvy na Daily Scrumu pro řešení možných kolizí nebo závislostí
• Explicitně určená kapacita týmu na: produkční podporu, malé změny a projekty

Obrázek č. 1 - jednotný backlog

Obrázek č.2 - Prioritizace

Hlavní přínosy

Hlavními přínosy zavedení Agile & Scrumu byly vyhodnoceny následující fakta:

• Vyšší spokojenost businessu (podle měření dotazníkem)
• Spokojený tým hrdý na své výsledky
• Done = Done
• Zvýšená kvalita (cca o 50% méně produkčních chyb)
• Time to market zásadně snížen (zrychlení o více než 50%, tj. z více než 6 měsíců na méně než 3)
• Pravidelné 14 denní release
• Vizibilita a transparentnost procesu vývoje pro celou společnost
• Rozšíření znalostí členů týmu -> vyšší flexibilita

Závěr

Už z výše zmíněných řádků plyne, že popisovaná transformace byla úspěšná a splnila očekávání. Právě práce s motivací a očekáváními jednotlivců je jedna z klíčových složek úspěšné transformace. V Directu byla veliká vůle a vize dosáhnout změny na pojišťovacím trhu z čehož vyplývala i motivace dělat věci správně, což znamená v tomto kontextu použití Scrumu a Agilních metod.

Dále se také jednoznačně ukázalo, že externí podpora Agilního coache významně zjednoduší a zrychlí zavedení Agilních metod. Je to hlavně zkušenost napříč odvětvími a společnostmi a praktiky, které jsou napsány ‘mezi řádky’ knih a článků o Agile & Scrumu.

Transformace nejen zlepšila pracovní prostředí a motivovala zaměstnance, ale měla i pozitivní ekonomický dopad na společnost. Zrychlení dodávek, snížená chybovost znamenala uspoření provozních finančních nákladů. Musíme zmínit i rychlejší odezva na požadavky businessu, které pomáhaly nabídku pojišťovny dynamicky měnit a optimalizovat na rychle se měnícím velmi konkurenčním trhu.

"Zmíněná případová studie je aplikovatelná mimo pojišťovnictví i na bankovní a jiné fintech společnosti včetně korporací středních a větších velikostí."

Autor:
Pavel Teichman

Agile Coach & Certified Scrum Professional^® at sochova.cz

Case-study ke stažení v PDF.