Napjainkban mind az agilis, mind a transzformáció kifejezésekkel találkozott már mindenki. Szembe jön velünk a különböző szakmai konferenciákon, meetup rendezvényeken, vállalati stratégiai monológokban, és természetesen az ilyen-olyan blogposztokban is. Van aki már csinálja, és van, aki szeretné csinálni. Így vagy úgy a legtöbb cég elgondolkodik rajta, hogy belevágjon. A folyamat nem egyszerű, de hatalmas eredményekkel kecsegtet, amennyiben sikeresnek bizonyul.
Amikor korábbi projektjeim során együtt dolgoztam svéd, német, olasz vagy magyar nagyvállalatotokkal, az autóipar, telekommunikációs cégek, és bankok felsővezetői egyaránt hasonló választ adtak, ha megkérdeztem, mit akarnak elérni az átalakulással. Az alábbi három dolog a lista élén áll:
lerövidíteni a time-to-market időket
javítani a felhasználói élményt
csökkenteni a fejlesztési költségeket
Ezen kívül persze növelni szeretnék a munkavállalóik elkötelezettségét és mindennapi morálját, vonzani a munkaerőpiac krémjét és úgy általában, javítani a pénzügyi mutatóikon.
A válaszok koránt sem meglepőek, hiszen a 21. század folyamatos és egyre gyorsuló ütemű változásait lekövetni és nyerő pozícióban maradni lehetetlen, ha az ember (vagy jelen esetben maga a vállalat) nem gondolkodik és rendezkedik be egy agilis(abb) működésre. Csakis azok a cégek maradnak ugyanis vezető helyzetben, amelyek egy nagyon magas szintű agilitással tudnak reagálni a piaci változásokra, a semmiből felbukkanó, frissen tőkeinjektált versenytársakra, a technológia őrült iramú fejlődésére, nem utolsó sorban pedig a szinte napról napra bővülő vevői igények garmadára.
A fentieket mind ígéri az agile. A kérdés csak az, hogyan kell ezt jól csinálni, mi a változás kulcsa.
Nemrégiben jelentet meg egy Portfolió cikkben hogy, számos magyarországi nagyvállalat elgondolkozott már az agilis transzformáción és kisebb-nagyobb lépéseket tett is ennek érdekében:
“ A K&H több területen is fejleszt "agilis-jellegű módszertant" 2015/2016 óta, ebben a szemléletben korszerűsítik a lakossági digitális csatornáikat és más ágakat a bankon és biztosítón belül.”
"A Budapest Bank informatikai területen alkalmaz agilis módszertant, ez érvényesül mind a frontend, mind pedig a middleware fejlesztésének területén.“
"Az OTP Bank már több projektjében alkalmazta az agilis módszertant.”
Felmerülhet a kérdés, hogy ha már ennyien és ennyi ideje foglalkozna vele, mégis miért nehéz ez még mindig. Az én tapasztalataim alapján az agilis átállással könnyű rövidtávú sikereket elérni limitált scope-pal. Például, ha egy szállítmányozó cég létre akar hozni egy agilis fejlesztő csapatot, hogy a sales-en dolgozó kollégákat segítő applikációt hozzon létre, néhány hónap alatt képes arra, hogy elérjen egy úgynevezett MVP-t (minimum viable product, melynek lényege, hogy egy egyszerűsített terméket dobunk piacra, amely azonban már rendelkezik annyi funkcióval, hogy az ügyfél legnagyobb nehézségeire már képes egy valamilyen szintű választ adni, és ezáltal értéket teremt: desirable, viable, feasible).
A néhány hónap a következő módon alakulna:
egy 3-4 hetes ügyféligény feltáró fázis során felmérik a fő probléma pontokat
majd ezt követi egy 1-2 hetes design sprint, ahol az ötletgenerálás és prototípus előállítás történik, melyeket már tesztelnek ügyfelekkel, így kialakítva a fejlesztendő koncepció vázát
ezek után már 2 hónap alatt lefejleszthető egy zöldmezős applikáció, melyet oda lehet adni a sales-eseknek, hogy elkezdjék használni.
A használat során kiderülnek a kezdeti hibák, további funkció fejlesztési ötletek merülnek fel, és az egész fejlesztés egy iteratív folyamatként megy tovább. Mindez összesen néhány hónap alatt. Mi hát akkor a nehéz ebben?
A fenti példa egy elszigetelt, jól lehatárolt, ráadásul frontend termékfejlesztési helyzetet ír le. Ez nem feltétlenül jelenti a teljes szervezetet átjáró kultúra adaptálását, sem a merev vállalati berendezkedés megváltoztatását, amelyek egy ilyen transzformációs törekvés szerves részét kell, hogy képezzék.
Ez utóbbi, teljes körű agilis átállással kapcsolatban a kihívások két oldalról szoktak megjelenni:
amikor a front-end fejlesztések back-end fejlesztéseket indukálnak a legacy rendszerekben
amikor a teljes szervezet próbál átállni az agilis működésre, és nem csak egy jól elszeparált projekt.
Az első esetében a problémák nyilvánvalóak, az IT realitások könnyen gátat szabnak az Üzlet által megálmodott változtatásoknak. Számos ilyen történt az elmúlt években, amióta a világ vezető tanácsadó cégei elkezdték promótálni az agilis működést ügyfeleiknél, de nem végeztek elég körültekintő felmérést azzal kapcsolatban, hogy az úgynevezett “zero-based design” megközelítéssel megálmodott új termék milyen backend változásokat követel meg. Ennek a veszélye az, hogy az ember csak a folyamat vége felé jön rá arra, hogy se a kitűzött dátum, és a bevállalt scope nem tartható.
Hogyan találhatja magát nagyon könnyen ebben a helyzetben a vállalat? Nézzünk erre egy példát:
egy rövidített ügyfél discovery fázis után kiválasztjuk a legnagyobb ügyfél nehézséget, amit ha megoldunk, akkor üzleti oldalról komoly számszerűsíthető értéket hozunk létre
ezután a Design Thinking szemléletét követve megpróbáljuk nulláról felépíteni az ideális folyamatot, amely egy nagyon kecsegtető elképzelés, tekintve, hogy az Uber is így alakította ki a szolgáltatását, nem pedig inkrementális módon javítgatva az eddigi meglévő taxi szolgáltatásokat
a módszertan következő lépése szerint az ideális folyamatot aztán végignézzük IT és egyéb megvalósíthatósági oldalról, és kialakítjuk a reális MVP elvárást.
A harmadik lépéssel kezdődik el megtorpanás, mivel egy kezdeti, magas szintű, outside-in elemzés nem feltétlen mutat rá a legacy rendszerekbe tíz vagy húsz év alatt implementált kötöttségekre. Márpedig ezek a rendszerek általában rendkívül komplex monolitok, amelyek messze nem a napjainkban hangsúlyozott microservice architektúrákra épülnek, így sokszor egy-egy apróbb változás is rengeteg implikációval jár, ezáltal hosszú hónapokig is tarthat. Az így kialakult helyzet oda vezet, hogy bár a front-end fejlesztések a tervezett ütemben haladnak, és a mock (backendhez nem integrált) ügyfél tesztek pozitív visszajelzéseket adtak, a backend integrációt mégsem sikerül megoldani hosszú hónapokig, egyes esetekben hosszú évekig.
Ebben az esetben a megoldás döntési oldalról egyszerű: a legacy rendszerérintettségek megértése nem opcionális, halasztható feladat, hanem a scope és határidők meghatározásának elengedhetetlen része.
A második esetben, a teljes szervezeti agilis transzformáció során viszont egy sokkal komplexebb problémába futunk. Számos aspektusra kell egyszerre odafigyelni és hasonló hangsúlyt fektetni. Az agilis transzformáció támogatásában világszinten elismert McKinsey például a következő vonatkozásokra hívja fel a figyelmet:
Stratégia. Struktúra. Folyamatok. Emberek. Technológia
Ilyenkor már előtérbe kerül az ún. “Organizational agility” vagyis a szervezeti szintű agilitás. A Forbes és ScrumAlliance által közösen kiadott ez évi riportból egyértelműen látszik, hogy a vállalati-szintű agilitás az, ami megkülönbözteti a vezető és a követő piaci szereplőket. És bár az általuk megkérdezett 1007 CEO 76%-ban bevallja, hogy leggyakrabban a technológiai területen váltottak agilisra, mégis 23%-uk azt is állítja, hogy a vállalatuk több funkciója is agilis irányelvek és felfogás szerint működik. Hamar belátható annak a hátulütője, ha csupán a termékfejlesztés aknázza ki az agilis fejlesztés gyors eredményeit, majd arra a marketing csapat nem tud időben kampányt kreálni.
A tiszta, konzisztens és széles körben implementált agilis alapelvek és működési modellek elengedhetetlenek a hosszú távú, fenntartható siker érdekében, és e siker záloga az alábbi három, el nem hagyandó mozzanat:
1. Felsővezetői agilis gondolkodásmód
A folyamatosan változó világban csak agilis vezetőkkel lehet jól navigálni. Hajóskapitányokra van szükségünk, akik a viharos tengeren is megállják a helyüket, nem pedig mozdonyvezetőkre, akiket a kötött pálya beszámíthatósága és előre láthatóan minimális kockázata mozgat. Az előbb említett Forbes tanulmány szerint 87%-ban meghatározó szóvivője az agilis átállásnak maga a CEO. Ő pedig húzza magával a teljes felső vezetést.
2. A megfelelő összetételű és minőségű tehetség bevonzása és folyamatos fejlesztése
Elképzelhető, hogy az agilis átállás szóvivője 87%-ban a CEO, de az biztos, hogy a transzformáció sikere 100%-ban a munkavállalókon dől el. Továbbmenve, a sikertelen transzformációk okaként 70%-ban a munkavállalói elköteleződés hiánya figyelhető meg.
Ez a folyamat már a megfelelő munkaerő keresésénél kezdődik, de ugyanilyen fontos a dolgozók tanítása, folyamatos fejlesztése. Itt szóba jöhetnek különböző agilis tréningek, de személyes coaching és mentoring is. Az ide befektetett idő és energia többszörösen megtérül. Ennek eredményeként a mindennapi munkavégzés is átalakul, szorosabb munkakapcsolatok alakulnak ki, sokkal gyakoribb egyeztetésekkel, több bizalommal, felhatalmazással, és természetesen szemmel látható, mérhető eredményekkel.
3. Az agilis kultúra és szervezeti berendezkedés támogatása, előmozdízása
Az agilitás nem egy folyamatcsomag, nem egy dobozos késztermék, amit a polcról levéve 3 lépéssel el lehet sajátítani, hanem egy felfogás, amely az együttműködést és az adaptációt helyezi a középpontba. Meg kell ehhez változtatni a szervezeti kultúrát? Igen. Meg kell tanulni máshogy kezelni a munkavállalókat? Igen. Meg kell a munkavállalóknak tanulni máshogy elvégezni a munkát? Erre is igen a válaszom. A kockázatvállalás, önálló gondolkodás, a szervezeti egységeken átnyúló együttműködés, sőt, a hibák beismerése mind ide tartozik, és a szervezet mint egész kollektív felelőssége is egy agilis transzformációs törekvésben.
Hogy a három közül melyik a nagyobb kihívás, azt most a kedves olvasó gondolataira bízom.