/*Blog module replace 'read more' text*/

Az agilitás nem cél, hanem eszköz

MINDSPIRE BLOG

Kövesse a MINDSPIRE közösségi oldalait!

dec 4, 2023 | Projektmenedzsment blog

Bevezetés: Az agilis átalakulás

Nyugodtan kijelenthetjük, hogy a 2020-as évek egyik legjelentősebb trendje a hazai nagyvállalatok körében az otthoni munkavégzés elterjedése mellett az agilis átalakulás. Egyre több multinacionális gyökerekkel rendelkező, vagy régiós szintű piaci szereplő dolgozik azon, hogy vállalati kultúrájában meghonosítsa az agilis alapelveket, annak érdekében, hogy előnyre tegyen szert általa versenytársaival szemben. Ami érthető is, hiszen az agilitás magában hordozza mindannak ígéretét, hogy:

  • gyorsabban szállítja az eredményeket,
  • rugalmasabban alkalmazkodik a gyorsan változó piaci környezethez és ezáltal az átalakuló üzleti igényekhez,
  • mindezt kevesebb adminisztrációval éri el, ugyanakkor növeli a transzparenciát,
  • továbbá jobb munkakörülményeket is teremt a dolgozók számára, hiszen magát az embert és a közvetlen, személyes kommunikációt helyezi előtérbe.
Gyenes Gergely

Gyenes Gergely

Agilis projektmenedzsment témavezető

Gergely több mint 20 éves tapasztalattal rendelkezik a lakossági hitelezés területén.
Egyaránt jártas az üzleti és az IT folyamatok tervezésében, valamint a projektmenedzsment, a tesztkoordináció és az adatelemzés terén is.
Elkötelezett a csapatmunkában, folyamatosan támogatja és ösztönzi a kollégáit a lehető legjobb teljesítmény elérésére.
Az elmúlt négy évben agilis product owner-ként dolgozott több lakossági hitelezési projekten, valamint részt vett szervezetek és projektek agilis transzformációjában is.

Vizsgáljuk meg, hogy mire van mindehhez szükség!

  • Először is kell egy jól átgondolt, mindenre kiterjedő módszertani leírás, hiszen maga az agilis manifesztó „csak” irányokat és értékeket fogalmaz meg. Azonban azt, hogy azokat hogyan lehet elérni és egy szervezet mindennapi életébe beilleszteni, már nem.
  • Majd kell egy ütemterv, amely mentén az eddigi szigorú hierarchiába rendezett szervezet átalakulhat az agilis működésnek megfelelő formára.
  • Mindenkivel meg kell ismertetni az alapelveket és az agilis módszertant, lehetőleg már az adott szervezetre igazított verzióval.
  • Végül pedig ki kell alakítani az új közösségi munkatereket, összeültetni az üzletet, az IT-t, egyéb közvetlen támogató területek képviselőit, és bevezetni valamilyen támogató szoftvert (mint például a JIRA és a Confluence).
Andras Linczmayer

Linczmayer András

Projektmenedzsment és Projektiroda szolgáltatás vezető

András több, mint 15 éves tapasztalattal rendelkezik a pénzügyi szektorban. Projektmenedzserként dolgozott kiemelt fontosságú projektekben, nagy létszámú belső és számos külső szállítóból álló csapatokat irányítva, sikeresen implementálva komplex rendszerarchitektúrákat és zöldmezős alkalmazásokat is.
Miközben a MINDSPIRE projektmenedzsment és projektiroda szolgáltatásokat vezeti, továbbra is nagyszabású projekteket irányít és támogat, szakmailag is bekapcsolódva a munkába.

Ezen feladatok végrehajtásához szükségünk lesz tapasztalt, az agilis módszertant már jól ismerő segítőkre, akik a csapatoknak a napi munka során valós formába tudják önteni a működést, legyenek ők scrum masterek vagy agilis coach-ok.

A szervezetünk most már agilis, hiszen nem üzleti specifikációkat írunk, hanem „user story”-kat fogalmazunk meg, amelyeket a „planning”-eken és a „refinement”-eken pontosítunk, pontozunk és darabolunk. Sprintekben dolgozunk, napi „stand up”-ot tartunk, az eredményeket pedig „demo”-kon mutatjuk be. A „retrospective”-eken pedig feltárjuk, hogy mi ment jól és mi kevésbé az elmúlt sprintben, hiszen ez a záloga annak, hogy egyre jobbak és hatékonyabbak legyünk.

Ha jobban belemegyünk a részletekbe, látni fogjuk, hogy még le kell győzzünk néhány kihívást.

IT architekturális kérdések az agilis működés kapcsán

Az elmúlt 20 évben a hazai nagyvállalati szektor szereplői (tisztelet a kevés kivételnek) hatalmas technológiai adósságot halmoztak fel. Ennek köszönhetően számos funkciót robosztus, monolit rendszerek szolgálnak ki, amelyek saját hatáskörben egyáltalán nem, vagy csak minimálisan fejleszthetők. Az IT architektúra a legtöbb esetben organikusan fejlődött az elmúlt évtizedekben, mindig az éppen aktuális trendek és igények gyors kiszolgálása mentén. Ráadásul nem egy helyen az is előfordul, hogy nagyon hasonló funkciókat, mint például a „reporting”, vagy az ügyfélnyilvántartás, más-más területeken, eltérő rendszerek szolgálnak ki.

Mindez miért releváns az agilitás szempontjából? Képzeljük magunk elé, hogy egy üzleti folyamat fejlesztésére és üzemeltetésére létre akarunk hozni egy agilis squad-ot. Tegyük fel, hogy ezt az üzleti folyamatot egy olyan „dobozos” rendszer szolgálja ki, amely két évtizeddel ezelőtt még egymaga tökéletesen el tudta látni ezt a feladatot. Mára azonban az organikus fejlődés következményeként már rá sem lehet ismerni. Számos nem „core” funkcionalitását kiszervezték más rendszerekbe, amelyekkel különböző interfészeken keresztül kommunikál. Így jelenleg az adott üzleti folyamat módosítása informatikai oldalról legalább két-három programnyelv és ugyanennyi kommunikációs technológia átfogó ismeretét igényli. Emellett üzleti oldalon is minimum ennyire összetett a szaktudásigény, hiszen szükségünk lesz termék és folyamat specialistára, jogi és compliance szakértőre is.

Az IT architektúra és szervezeti keretek összefüggései az agilis modellben

Az agilitás egyik legnagyobb erénye, hogy egy-egy csapatot felhatalmazunk arra, hogy önálló döntéseket hozzon, saját maga határozza meg, hogy egy-egy üzleti igényt hogyan kíván a rendelkezésére álló eszközökkel és erőforrásokkal a leghatékonyabban megvalósítani. Ez elengedhetetlen ahhoz, hogy gyorsan tudjon reagálni a folyamatosan változó környezetre.

A valóságban egy önállóan E2E szállítani képes squad felállítása sokszor feszegeti az agilis kereteket. A gyakorlatban alapvetően az alábbi két lehetőség kínálkozik:

  • Felállítunk egy squad-ot, amely minden komponens tekintetében tartalmaz kompetens erőforrásokat. Így létrejön egy 13-18 fős csapat, amely ugyan képes az adott folyamat tekintetében minden felmerülő hibát kivizsgálni, kijavítani és azt új elemekkel is tudja bővíteni, de méreténél fogva szétfeszíti az agilis kereteket. Ezáltal az agilis ceremóniák hatékonysága jelentősen romlik, valamint a csapattagok közötti információáramlás is sérül. Idővel talán egyes kompetenciák összevonhatóak lesznek és csökkenthetővé válik a létszám, de addig biztosan lesznek olyan csapattagok, akik számára a squad nem tud folyamatosan teljes munkaidőt kitöltő feladatot biztosítani, ami hátrányosan érinti az elköteleződést és az úgynevezett „tulajdonosi szemlélet” kialakulását.
  • Felállítunk egy olyan squad-ot, amely létszámát tekintve megfelel az agilis kereteknek, de lesznek olyan funkciók, amelyeket a squad önállóan nem lesz képes fejleszteni, javítani. Ebben az esetben a csapat, mint egy termékért és folyamatért felelős egység, megrendelői szerepkörben fog megjelenni más agilis squad-ok felé, ami függőséget okoz. Ez bizonyos kompetenciákat érintő feladatok esetében meggátolja az önálló és folyamatos szállítás lehetőségét, ami szintén sérti az agilis alapelveket.

A gyakorlatban a fenti két megoldás mellett számos egyéb „hibrid” felállás is kialakult.

Mint például az, amikor bizonyos speciális erőforrások ugyan hivatalosan egy-egy squad tagjai, de a valóságban egy olyan kompetencia pool-ba tartoznak, ahonnan igény szerint egy-két sprint, vagy negyedév erejéig beugróként bedolgoznak egy meghatározott squad-ba.

Létezik olyan módszertan is, amikor az egyes erőforrásokat elkezdik megosztani squad-ok között valamilyen százalékban, így az adott munkavállaló kénytelen egyszerre több squad életében is napi szinten közreműködni és részt venni a ceremóniákon, ami hosszabb távon, mind a munkavállaló, mind pedig a squad-ok tekintetében feszültséget szül.

Azt látjuk, hogy a legtöbb esetben – az örökölt architektúrának köszönhetően – nem is valósul meg a teljes szervezet agilizálása.

Több, az agilis átállásba bevont területtel szoros együttműködésben dolgozó egyéb szakterület más-más ritmusban végzi napi feladatait, rengeteg belső és külső szállítói függőség is fennmarad. Ez folyamatos koordinációt, egyeztetést, többlet tervezést ró a már agilisan működő csapatokra, növelve a leszállítási kockázatokat, hisz nincs megfelelő ráhatásuk a külső környezetükre.

Szervezeti kérdések az agilis működés kapcsán

Az agilis módszertan alapvetően lapos mátrix szervezetben gondolkodik, valamint abban, hogy az operatív döntéseket a lehető legalacsonyabb szintre delegálja, oda, ahol az érdemi munka folyik. Ebben a struktúrában alapvetően két szint létezik vertikálisan:

  • A menedzsment szint, aki közvetlenül a vállalatvezetésnek jelent, a fő feladatai pedig a vállalati célokhoz illeszkedő stratégiaalkotás az adott területen belül, a munkáltatói jogkörök gyakorlása, valamint az operatív szintek kialakítása és a feladatokhoz igazítása.
  • Az operatív szint, a Product Owner, aki egy-egy squad-ot irányít. Ő az, aki kialakítja a napi működést, meghatározza az előrehaladást, lebontja a stratégiát és konkrét feladatokba önti azt a csapat számára. Sprintről-sprintre haladva fogadja el a csapat teljesítését, vállalásait, vagy tesz észrevételeket a megvalósult fejlesztések és a vállalt jövőbeni szállítások vonatkozásában, ezzel terelve a csapatot az áhított cél elérése irányába.

Emellett támogató jelleggel jellemzően létrejönnek olyan horizontális, szakmai szintek, melyek vezetője elsősorban azért felel, hogy az egy-egy kompetenciába tartozó kollégák azonos minőséget és tudásszintet képviseljenek. Általában ők végzik a kiválasztást, valamint azon szakmai sztenderdek kialakítását, amelyek mentén az adott kompetenciába tartozó munkatársak ellátják a feladataikat.

Nem véletlen, hogy az agilitás, mint módszertan az IT szektorban látott napvilágot, és elsősorban azon startup cégekben vált hatékony eszközzé, amelyekben nem volt előzménye a hierarchikus szervezeti kultúrának. Egyszerűen számukra ez volt az alap, amire építkeztek, ez a szemlélet és gondolkodásmód határozta meg működésüket már a kezdetektől fogva.

Agilis projektmenedzsment cikk illusztráció

Az úgynevezett tradicionális nagyvállalatok esetében az agilis működésre történő átállást nem elegendő munkaszervezési oldalról megközelíteni.

Ahhoz, hogy egy szervezet sikeres agilis transzformáción menjen keresztül, szükség van az IT architektúra felülvizsgálatára és bizonyos esetekben gyökeres átalakítására is. Ez sok esetben fájdalmas, hosszadalmas és költséges lépés, de ha az agilitás útját választjuk, akkor elkerülhetetlen.

Miért érdemes belevágni az agilis átalakulásba?

Az agilis működési modell bevezetése, valamint az agilis átalakulás a tapasztalatok alapján komoly kihívások elé állíthatja a szervezeteket, azonban az előnyei és az elért eredmények messze felülmúlják az átalakulás során tapasztalható nehézségeket.

Ahogyan a cím is fogalmaz: az agilitás csupán egy eszköz, nem pedig az elérendő cél. Ha így tekintünk rá, és tudomásul vesszük, hogy az agilis transzformáció rengeteg időt és áldozatot igényel, mind anyagi, mind pedig szervezeti oldalról, illetve csak ott kívánjuk alkalmazni, ahol annak valóban létjogosultsága van, akkor van esély arra, hogy beváltsa az agilis manifesztó által tett ígéreteket. Ha azonban úgy tekintünk rá, mint a 2020-as évek szervezeti trendjére, egy varázspálcára, amellyel minden korábbi vállalati probléma egy csapásra megoldódik, akkor rengeteg csalódásban lesz részünk, és az erőfeszítések ellenére kudarc és szervezeti visszarendeződés lesz az eredménye.

A sok nehézség ellenére nem szabad megfeledkeznünk arról, hogy ha egy nagyvállalati szervezet elkötelezi magát az agilitás mellett, annak rövid távon is számos előnye lehet még akkor is, ha a szervezeti kultúra csak hosszú évek szisztematikus munkájával változtatható meg. Az egyik ilyen elvitathatatlan előny azon láthatatlan falak lerombolása, amelyek a hagyományos szervezetben az üzlet, mint megrendelői oldal és az IT, mint szállítói oldal között húzódnak. Azáltal, hogy ezeket az oldalakat megszűntetjük és az érintett szereplőket egy csapatba, egy fizikai térbe helyezzük, elindítunk egy olyan együttműködést, egy olyan közös gondolkodást, ahol az üzleti fél megérti a rendelkezésre álló IT architektúra korlátait, egy IT fejlesztő pedig az üzleti igények fontosságát. Így képessé válnak közösen olyan kompromisszumokat találni, amely a rendelkezésre álló keretek között a lehető leggyorsabban megvalósítható, és a lehető legjobban kielégíti az üzleti elvárásokat. Ezáltal nem ellentétes oldalon álló felek, eltérő érdekekkel, hanem egy csónakban ülő, egy irányba evező, egymást támogató kollégák lesznek.

És hogy kezdjünk hozzá? Javasoljuk, hogy tárjuk fel a szervezetben azokat a területeket, projekteket, amelyek esetében maradéktalanul megvalósíthatóak az agilis alapelvek, és lépésenként vezessük át a szervezetet az agilitásba, az IT architektúrával párhuzamosan.

Ha kérdése van az agilis átalakulással kapcsolatban, vegye fel a MINDSPIRE Consulting szakértőivel a kapcsolatot!

Szerzők:

Gyenes Gergely és Linczmayer András

Ismerje meg a MINDSPIRE kapcsolódó szolgáltatásait:

 

Projektmenedzsment
szolgáltatások

Projektiroda
szolgáltatások

Az agilitás nem cél, hanem eszköz
Project management contact form

Kérdése vagy megjegyzése van a bejegyzéssel kapcsolatban?

Küldje el üzenetét és munkatársaink felveszik Önnel a kapcsolatot!

Projektiroda ikon

Legújabb Projektiroda referenciáink

Többet szeretne tudni Banki projektiroda szolgáltatásainkról?

További információkért kattintson ide:

Projektmenedzsment szolgáltatások ikon

Legújabb banki és biztosítói projektmenedzsment referenciáink

Többet szeretne tudni projektmenedzsment szolgáltatásainkról?

További információkért kattintson ide:

Share This