Keď kríza vypukne tri mesiace pre vianočnou kampaňou a Agile

Pred niekoľkými rokmi ma pozvali do jednej poisťovne pomôcť so zavedením Agilných praktík.Nešlo o celkovú transformáciu. Išlo o inovatívny poistný produkt, ktorého uvedenie bolo už marketingovo dohodnuté na Vianoce. A to musí byť presné, ide o zmluvy s médiami a naplánovanými kampaňami mesiace vopred a dátumy iba tak nezmeníte. Navyše kampane vo vianočnom čase sú drahé. A vždy je dobré mať aj produkt, ktorý kampaňujete, vo funkčnom stave.

Výzvou bol práve stav projektu pre zmenu IT systémov a samotné spustenie produktu. Biznis spolu s biznis architektami a produktovými vlastníkmi niekoľko mesiacov pripravoval detaily požiadaviek, podľa ktorých by následne IT malo vytvoriť svoje implementačné požiadavky a mohol realizovať zmeny. Projekt samotný bol typu fixed-time kvôli už spomínaným kampaniam. Samozrejme sa chcelo spraviť čo najlepší poistný produkt. Komplexita tak bola veľká a ešte viac znásobená inováciami.  A tak, 3 mesiace pred spustením kampaní, projekt začal horieť.

Prišiel spásonosný nápad „s Agile to dokážeme“. No z Agile v tomto prípade stačila aplikácia základných princípov – transparentnosť, minimum, zbytočnosť, prírastok, investícia a nie náklad.

Čo živí tento oheň?

Po prvom ponorení sa do detailov sme identifikovali absolútne základný problém. Produktový Backlog, ako ho poznáme v Agile, v podstate existoval iba vo forme Excelu s viac než 70 stĺpcami a stovkami riadkov pre produktové aj IT features viacerých IT systémov. Jeden obrovský a neprehľadný bordel. Ale zato poriadne detailne všetko spísané. Transparentne? Nie, pre stromy nebolo vidno les.

Potrebovali sme získať absolútny manažérsky prehľad.

Potrebovali sme kvalitne vytvorený backlog. Potrebovali sme ho v štruktúrovanej a hierarchickej forme.  Potrebovali sme požiadavky napísané zrozumiteľným jazykom, aby sme vytvorili podmienky pre zladenie všetkých. Biznisu, 4 produkťákov, biznis architektov, IT architektov, developmentu aj testerov. A navyše sme nemali nástroj, takže sme to potrebovali v čo najjednoduchšej a ľahko manipulovateľnej forme.

Keď horí, zachránia Ťa postity.

Aby sme sa rozmotali, zatvorili sme sa so štyrmi projektovými manažérmi a biznis architektami do vyhradenej miestnosti. Na štyri nekonečné dni. Chcel som po nich, napriek tomu, že to znelo nelogicky a iracionálne, aby  sme spolu ten obrovský nešťastný Excel prepísali na postity. Stovky postitov. Prepísali ručne, perom. To predsa nedávalo logiku.  Alebo?

Prepisovaním sme prišli na množstvo duplikovaných požiadaviek. Zapísaných v inej forme, ale boli to tie isté veci. Hneď sme mali niekoľko desiatok požiadaviek menej.

Prepisovaním sme zistili chýbajúce požiadavky. Fundamentálne, bez ktorých by produkt nefungoval. A to napriek tej veľkej niekoľkomesačnej snahe na príprave. Stane sa keď je toho veľa.

Prepisovaním sme našli hierarchiu požiadaviek. Zistili sme princípy pre delenie požiadaviek podľa biznisových aspektov produktu.

Prepisovaním sa prišlo na to najdôležitejšie. 30% požiadaviek už nebolo relevantných. Za to obdobie príprav sa jednak zmenili biznis podmienky na trhu a zároveň sa IT systémy posunuli, takže viaceré nebolo možné už implementovať navrhovaným spôsobom.

Prepisovaním sa prišlo na priority. Zistili sme, že pôvodne navrhované priority boli nesprávne navrhované. Jasné že to tak muselo skončiť. Požiadavky narástli časom v komplexite a kto by dokázal neustále udržiavať priority v takej kope.

Prepisovaním sme prišli na to, že pred implementáciou produktu boli potrebné aj ďalšie rozvojové úlohy, tzv. Enablers. Také ktoré pripravia schopnosti v IT systémoch a na ktoré sa následne dá nabaliť ďalšia funkčnosť.

Prepisovaním sme identifikovali základné delenie produktu. A aby sme sa v tom vyznali, použili sme farby na odlíšenie. O to väčšia bola transparentnosť.

Prepisovaním sa nakoniec prišlo na kandidátov na Minimum Marketable Product. A práve toto bol môj zámer.

Našli sme zlatý rez umožňujúci komerčné spustenie produktu v danom termíne, ktoré bolo realistické. Na rovinu, nie nebol to pôvodne zamýšľaný celý produkt. Pretože nikto nemal odvahu povedať pravdu, že sa to nedá stihnúť.

Našli sme aj stratégiu ako spustiť predaj produktu aj za cenu, že prípadné vyplácanie poistnej udalosti nastane aj v prvom mesiaci a poisťovňa to bude musieť riešiť papierovo. Bola to akceptovateľné riziko. Pretože aká je pravdepodobnosť že poistenec zomrie do mesiaca od podpísania životného poistenia? Nie je nulová, ale ani nezvládnuteľná papierovo. A za ten prvý mesiac od spustenia predaja produktu bolo možné dokončiť elektronizáciu aj riešenia poistných udalostí.

Keď to už iba tleje

Výsledok? Portské pri pohľade na práve bežiacu reklamu na nový inovatívny poistný produkt v telke.  S vedomím, že implementácia bola dokončená načas a kampa§ v telke neklame. Produkt sa mohol predávať.

Poučenie?

1. Keď je kríza, vytiahnite postity, vyhrňte rukávy a naštartujte spoločný review.
2. Otvorte oči a hľadajte príležitosti na zmenšenie rozsahu. Čo nie je potrebné? Čo potrebujeme neskôr?
3. Zorganizujte si transparentne backlog tak, aby sa v ňom vyznala aj vaša stará mama.
4. Píšte požiadavky tak, aby to pochopila aj tá stará mama.
5. Menej je viac. Keď si myslíte, že ste našli minimum, vždy sa ešte dá zmenšiť o jednu, dve požiadavky.
6. Pracujte v iteráciách. Spísať. Zorganizovať. Vyhodiť zbytočnosti. Priorizovať zostávajúce. Identifikovať inkrementy, MMP. A poďme na ďalší vertikálny rez produktu.
7. Premýšľajte nie nákladovo, ale investične. Investovať 4 dni do backlogu ušetrí šialené mandays vo vývoji správneho produktu správnym spôsobom.
8. Nie je to jednorazová aktivita. Naštartujte pravidelnú prácu nad backlogom a zemnami, ktoré sa objavia počas vývoja.
9. Transparentnosť, transparentnosť, transparentnosť. Netkvie iba v kartách na stenách. Skúste používať farby pre segmenty klientov. Alebo IT systémy.
10. Jeden, ale skutočne jeden, backlog. Jeden.

Lebo menej je viac.