Provokatív kérdés, tudom. De megéri feltenni. Tapasztalatom szerint a Scrum formális alkalmazása pénzügyi szektorbeli nagyvállalatoknál az esetek jelentős részében nem működik jól. Nem azért, mert az agilis elvek rosszak, hanem mert a kontextus más, és ezt ritkán mondják ki hangosan.
Röviden
- A Scrum autonóm csapatra, gyors döntéshozatalra és üzleti kézben lévő backlogra épül. Bankban, biztosítónál, lízingcégnél ezek ritkán teljesülnek.
- Ha a szervezet nem változik, a Scrumból csak a forma marad meg: a daily státuszriport lesz, a sprintet felülírják a sürgős feladatok.
- Ami valóban működik: iteratív szállítás, folyamatos prioritizálás, transzparens heti kommunikáció, ceremóniák nélkül is.
- A Scrum Master feladataira szükség van, de betöltheti tapasztalt üzleti elemző, projektmenedzser vagy tech lead is.
Miért más a kontextus pénzügyi szektorbeli vállalatoknál?
A Scrum keretrendszert szoftverfejlesztő csapatoknak találták ki: autonóm csapat, közvetlen kapcsolat az ügyféllel, gyors döntéshozatal, minimális bürokrácia. Egy nagyvállalati biztosítónál vagy banknál ezek a feltételek általában nem teljesülnek.
A döntéshozatal nem gyors. Egy biztosítási termék változtatásához compliance review kell. Egy banki rendszer módosításához architekturális jóváhagyás kell. Egy lízingcégnél a szerződéses feltételek változtatásához jogi egyeztetés kell. Ezek a folyamatok heteket vesznek igénybe, nem napokat, és nem gyorsíthatók fel azzal, hogy bevezettük a Scrumot.
A „csapat” nem autonóm. A fejlesztők, a BA-k, a tesztelők, az üzleti területek és az IT üzemeltetés különböző szervezeti egységekhez tartoznak. Mindenkinek van felettese, és mindenkinek más a prioritása. A cross-functional csapat felállítása szervezeti átalakítást igényel, nem csak módszertani döntést.
A backlog nem az üzleté. Pénzügyi szektorbeli vállalatoknál a fejlesztési igények sokszor szabályozói elvárásokból, audit megállapításokból vagy vezetői döntésekből fakadnak, nem egy product owner prioritizálásából. A „legértékesebb funkció először” elv nehezen alkalmazható, ha a sorrendet a compliance és a szabályozói határidők diktálják.
Mi történik ilyenkor általában?
A Scrum bevezetésre kerül. Lesznek daily standupok, sprint planningek, retrospektívek. Mindenki elvégzi a Scrum-képzést, a csapat megkapja a Jira-hozzáférést. Hat hónappal később:
- A daily standup státuszjelentéssé válik. A Scrum Guide szerint a 15 perces daily célja a sprintcél felé tett haladás ellenőrzése és a terv igazítása, a gyakorlatban viszont „mit csináltam tegnap” riport lesz belőle.
- A sprint planning megtörténik, de a sprint közben jönnek az üzlettől a „sürgős” feladatok, és felülírják a tervezett munkát.
- A retrospektív kiesik a zsúfolt naptárból.
- A Scrum Master ideje nagyrészt adminisztrációval telik.
Ez nem a Scrum Master hibája. Ez a szervezeti valóság.
Mi a Scrum Master dolga, papíron és a gyakorlatban?
A Scrum Guide (2020) szerint a Scrum Master a Scrum csapat hatékonyságáért felel, és három irányba szolgál: a csapatot, a product ownert és a szervezetet. Pénzügyi szektorbeli nagyvállalatnál ez sokszor egészen másképp néz ki:
| Feladat a Scrum Guide szerint | Ami a gyakorlatban gyakran történik |
|---|---|
| Az önszerveződés és a cross-functional működés coacholása | A csapattagok más-más vezetőnek jelentenek, az önszerveződésnek nincs tere |
| Az akadályok elhárítása | Az akadály egy jóváhagyási folyamat vagy egy másik szervezeti egység, amire nincs ráhatása |
| Az események hasznos, időkereten belüli lebonyolítása | Meetingszervezés, jegyzőkönyv, Jira-adminisztráció |
| A product owner támogatása a backlog kezelésében | A backlogot a compliance és a szabályozói határidők rendezik sorba |
| A Scrum bevezetésének vezetése a szervezetben | Nincs mandátuma a döntési struktúra megváltoztatására |
Akkor mi működik pénzügyi szektorbeli projekteknél?
Az agilis szemlélet, nem feltétlenül a Scrum ceremóniái. Az Agilis Kiáltvány (2001) értékei, például a működő szoftver és a változásra való reagálás, keretrendszer nélkül is alkalmazhatók. Három dolog, amit valóban értékesnek tartok pénzügyi szektorbeli IT projekteken:
Iteratív szállítás kisebb egységekben. Nem kell két évet várni az első éles verzióra. Ha a rendszer modulonként szállítható, a visszajelzések hamarabb érkeznek, és a kockázat kisebb. Ez nem Scrum-specifikus, hanem általános agilis elv.
Folyamatos prioritizálás. A backlog karbantartása és a prioritások rendszeres egyeztetése az üzlettel értékes, függetlenül attól, hogy „sprint planningnek” hívják-e.
Transzparens kommunikáció a haladásról. Egy heti státuszlevél, amely pontosan leírja, mit végeztünk el, mit vállalunk a következő hétre, és mi nem valósult meg (és miért nem), több értéket ad, mint egy formális Scrum-esemény egy diszfunkcionális szervezeti struktúrában.
Mikor működik jól a Scrum pénzügyi szektorbeli környezetben?
Az objektivitás kedvéért: vannak helyzetek, amikor a Scrum pénzügyi kontextusban is jól működik.
Dedikált, valóban autonóm csapat. Ha az üzlet és az IT közösen allokál egy dedikált csapatot egy projekthez, közös helyszínnel, közös naptárral és valódi döntési jogkörrel, a Scrum jól működhet. Ez ritka, de előfordul.
Greenfield fejlesztés. Amikor valami teljesen újat építünk, és nem egy meglévő legacy rendszert fejlesztünk tovább, az iteratív megközelítés valódi értéket ad. Ezt egy pénzügyi szektoron kívüli projektünk is jól mutatja: a Mitigia carbon credit platform fejlesztésénél az üzleti logika és a szoftver párhuzamosan formálódott. Klasszikus kéthetes sprintek helyett 3 iterációs fázisban, heti státuszlevelekkel dolgoztunk, és 6-7 hónap alatt a teljes scope-ot leszállítottuk.
Fintech és insurtech startupok. Ahol a szervezet lapos, a döntéshozatal gyors és a csapat valóban autonóm, ott a Scrum jól alkalmazható.
Ellenőrzőlista: készen áll a szervezet a Scrumra?
- Van dedikált, legalább a projekt idejére stabil csapat, amely nem dolgozik párhuzamosan más projekteken?
- A product owner maga dönthet a prioritásokról, bizottsági jóváhagyás nélkül?
- A fejlesztési igények nagy része üzleti értékből, nem szabályozói vagy audit kényszerből fakad?
- A szükséges jóváhagyások (compliance, architektúra, jog) beférnek egy sprintbe?
- A vezetés kész megvédeni a sprintet a menet közben érkező „sürgős” feladatoktól?
- Van ideje és mandátuma a Scrum Masternek a szervezeti akadályok elhárítására?
Ha a kérdések többségére nem a válasz, a Scrum formális bevezetése helyett érdemesebb az agilis gyakorlatokkal kezdeni. Hogy ilyenkor mi a jobb választás, arról a Kanban vagy Scrum cikkünk szól.
Akkor kell-e Scrum Master?
Igen, de nem feltétlenül abban a formában, ahogy a tankönyvek leírják. Amit egy pénzügyi szektorbeli IT projekten valóban be kell tölteni: valaki, aki védi a csapat fókuszát a szervezeti zavaroktól, kommunikál a különböző szervezeti egységek között, transzparensen dokumentálja a haladást és az akadályokat, és segít a csapatnak folyamatosan javítani a munkamódszerén.
Ezt a szerepet nem feltétlenül egy „Scrum Master” tölti be, hanem egy tapasztalt üzleti elemző, egy erős projektmenedzser vagy egy agilis szemléletű tech lead. A titulus kevésbé fontos, mint a kompetencia és a szervezeti pozíció. (Hogy az üzleti elemző és a product owner szerepe hol válik el, arról itt írtunk: BA vagy Product Owner?)
A legkárosabb, amit egy szervezet tehet: bevezeti a Scrum terminológiáját és eseményeit, de nem változtat a döntéshozatali struktúrán, a szervezeti határokon és a prioritizálás folyamatán. Az eredmény: a Scrum adminisztratív terhe megmarad, az agilis értékek nem érvényesülnek, és a csapat igazságtalanul elveszíti a bizalmát az agilis módszertanban.
Amit a FrontX-nél másképp csinálunk
- Az egyedi szoftverfejlesztési projektjeink nem „Scrum-projektek”, hanem strukturált, iteratív projektek, amelyek az agilis elveket a pénzügyi szektor kontextusához igazítják.
- Heti státuszlevél, folyamatos stakeholder-kommunikáció, moduláris szállítás és transzparens akadálykezelés: nem ceremóniák, hanem valódi érték.
- Az üzleti elemző végig jelen van. Nem a Scrum Master helyett, hanem azért, mert pénzügyi szektorbeli projekten az üzleti igény gazdája fontosabb, mint a sprintesemények facilitálása.
- Ha egy ügyfél csapatához csapatkiterjesztésben csatlakozunk, a meglévő módszertanához igazodunk, és ott segítünk, ahol a gyakorlat elakad.
Ha olyan IT projekted van, ahol az agilis módszertan bevezetése nem hozta a várt eredményt, szívesen megnézzük, miért: kérj ingyenes konzultációt.
Gyakran ismételt kérdések
Működik a Scrum pénzügyi szektorbeli IT projekteknél?
Feltételektől függ. A Scrum jól működik dedikált, autonóm csapatoknál, greenfield fejlesztéseknél és fintech startupokban. Nagyvállalati pénzügyi környezetben, ahol a döntéshozatal lassú, a csapat nem autonóm, és a backlogot compliance elvárások diktálják, a Scrum formális alkalmazása általában nem hozza a várt eredményt. Az agilis szemlélet értékes marad, de a gyakorlatot a szervezethez kell igazítani.
Mi a különbség a Scrum és az agilis szemlélet között?
Az agilis szemlélet értékek és elvek gyűjteménye (Agilis Kiáltvány, 2001): iteratív szállítás, folyamatos visszajelzés, rugalmasság, szoros együttműködés. A Scrum egy konkrét keretrendszer, amely eseményekkel, felelősségi körökkel és artefaktumokkal valósítja meg ezeket az elveket. Lehet agilisan dolgozni Scrum nélkül is, és pénzügyi nagyvállalati környezetben ez sokszor célravezetőbb.
Mi a Scrum Master feladata?
A Scrum Guide szerint a Scrum Master a Scrum csapat hatékonyságáért felel: coacholja a csapatot az önszerveződésben, elhárítja az akadályokat, gondoskodik róla, hogy az események hasznosak legyenek és időkereten belül maradjanak, támogatja a product ownert, és segíti a Scrum bevezetését a szervezetben. Nem projektmenedzser és nem meetingszervező.
Mikor érdemes Scrum Mastert alkalmazni pénzügyi szektorbeli projekten?
Ha valóban dedikált, autonóm, cross-functional csapat áll rendelkezésre, a szervezet kész a döntéshozatali struktúra megváltoztatására, és a projekt jellege lehetővé teszi az iteratív szállítást. Ha ezek a feltételek nem teljesülnek, egy agilis szemléletű, tapasztalt üzleti elemző vagy projektmenedzser hatékonyabb lehet.
Miért nem működik a Scrum nagyvállalati pénzügyi környezetben?
Négy fő ok miatt: a döntéshozatal lassú, és módszertani változással nem gyorsítható; a csapat szervezetileg nem autonóm; a backlogot külső kényszerek diktálják; és a szervezeti kultúra nem biztosítja az eseményekhez szükséges időt. Ezek szervezeti problémák, nem technikai vagy módszertani problémák.
Behán László a FrontX Kft. ügyvezetője és társalapítója. Korábban a Signal Biztosító CIO-ja, a Groupama Biztosító fejlesztési és adattárház-vezetője, valamint a LeasePlan Hungaria igazgatóságának tagja volt operációs igazgatóként. 25 év IT és üzleti vezetői tapasztalattal rendelkezik a pénzügyi szektorban. LinkedIn-profil
