Az agilis transzformáció 7 főbűne és 5 olyan erénye, ami reméljük, velünk marad

Írta Fodor Andrea 

Agilis transzformáció – miért nem hozza az elvárt eredményt?

agilis transzformáció

Mi az oka annak, hogy az  agilis transzformáció nem mindig hozza a várt eredményt?

Láttam jól működő agilis projekteket. A közös jellemzőjük volt, hogy a csapat vezetője – mindegy, hogy product owneri vagy scrum masteri szerepkörben volt – jó szakember volt. Vett már részt sikeres projektek leszállításában, ismerte az informatikai rendszerek tervezési és fejlesztési folyamatait, értett a témához annyira (vagy nagyon gyorsan felszedte a tudást), hogy képes legyen a csapatot szakmailag is jó irányba állítani. Ők igen kiváló eredményeket értek el az agilitás segítségével – igaz, korábban a klasszikus módszertannal sem volt leszállítási problémájuk.  

Egyedi jó eredmények vannak. De vajon mi lehet az oka, hogy sok helyen – főleg a nagyvállalatoknál – az agilis transzformáció, bár látszólag rugalmasságot biztosított, ritkán vezetett az ígért gyorsasághoz. Sőt, jellemző a rework, a nagyobb feladatok késése, a félmegoldások (rosszul értelmezett minimum viable product) miatti káosz, a kiégés. 

Jelen cikkünkben összeszedtem azokat a pontokat, amit az agilis transzformáció kísérletek „főbűnének” tartok.  Valamint azokat a jó dolgokat, amit ha értelmesen csinálunk, az agilitás elemei behozhatnak a cégek életébe.  Szigorúan szubjektív lista következik, magyarázatokkal.

Az agilis transzformáció 7 főbűne

transzformáció folyamata

Ezen „bűnök” leginkább azon szervezeteknél jelentkeznek, akik product alapú, continuous delivery-re épülő agilis transzformációkat valósítottak meg:  

  • Ellehetetlenítette, illetve leépítette a projektműködést: sok helyen a „projekt” szót kimondani sem lehetett. Rövid időre, de van, ahol 1-2 évre bizonytalanná vált a projektvezetők és a business analystek szerepe. Mindezt olyan vállalati környezetben, ahol a fejlesztési igények akár 80-100%-a több rendszeren átívelő fejlesztést fed le, amit kommunikáció és több lépcsős tervezési folyamat nélkül nem lehet megugrani.

    Természetesen mindenki rájött, hogy projektekhez projektvezető kell, és a business analystek is visszaszivárogtak a rendszerbe, de addigra a projekteket támogató környezet teljesen megszűnt, így jóval nehezebb lett a projekteket menedzselni. 
  • Mindent szögnek néz, és egy csatornán kezel: ugyanazon folyamatban kezeli a projekt méretű, sok összefüggéses, sok szereplős igényeket, mint a néhány percet igénybe vevő hibajavításokat. Míg az utóbbira a folyamat tökéletes lenne, egy nagy, sok stakeholderes, sok összefüggést tartalmazó feladatnál más megközelítésre lenne szükség.
  • Elfelejtette, hogy a fejlesztési folyamat nem a fejlesztési igény leadásánál kezdődik, 20 évet ugorva vissza az időben. A product / continuous delivery típusú agilitás jellemzően kihagyja vagy értelmezhetetlenül lerövidíti az igényfelmérés, a needs assessment szakaszát (melynek során tisztázzuk az elérendő célokat, mérlegeljük a célokat elérni segítő megoldási alternatívákat), valamint kihagyja az összefüggéseket megmutató magas szintű tervezést. Ez nem baj, ha egy-egy kisebb funkciót jelentő fejlesztési igényről van szó, de egy nagy, komplexebb igény határidőben való leszállítását ellehetetleníti. 
futószalag projektek egymás után - continuous delivery
  • Kiégeti az embereket: egyre több helyről hallom, hogy a „continuous delivery”  nagyon hamar kiégeti az embereket. Ennek egyik oka, hogy sok helyen 130% -ra tervezik a kapacitást, a szükséges 80% helyett. A másik ok a „continuous” szóban rejlik, hogy egyszerű futószalaggá változtatta az egyébként kreatív és érdekes munkát. Egy nagyobb release végén nincs idő megállni ünnepelni, mert máris ezerrel ömlenek be a hibák.
  • Elveszi az emberektől azt az érzést, hogy értelme van a munkájuknak: sok helyen tapasztalom, hogy a „nagykép” az, hogy mit is kell elérni és miért, elvész az apróra lebontott feladatok tengerében. Kollégák panaszkodnak, hogy nem látják át, mit miért csinálnak, át kellett definiálniuk a sikert  arra, hány „task”-ot pipáltak ki egy nap. 
feladat kipipálása
  • Magára hagyja az üzletet a megoldás kitalálásában: sok helyen csak akkor allokálnak erőforrást (akár Business Analyst vagy Solution Architect erőforrást)  konzultációra, amikor már van elfogadott igény. Ezáltal az üzleti területek magukban pöröghetnek a megoldás kitalálásán, ami általában átgondolatlan, nem teljeskörű, ezáltal becsülhetetlen specifikációkat eredményez (lásd bővebben: Elvárható-e az üzleti területektől, hogy követelmény specifikációt írjanak? cikkben).
  • Elhiteti, hogy van egy ember, aki tudja a tutit: egyszer vitáztam egy agilis szakértővel, aki azt állította, hogy az üzleti  Product Owner majd odaáll a csapat elé, és elmagyarázza nekik, hogy mit kell csinálniuk. Mindezt egy olyan környezetben, ahol rengeteg (jog)szabály, és több ország üzleti folyamata érintett. Ez nemhogy egy ember fejében nincs meg, hanem sokszor hosszú workshopokkal teli heteket vesz igénybe, hogy megtaláljuk azt a folyamatot/megoldást, ami egyik terület működését sem vágja jelentősen keresztbe. Ez a folyamat néha több időt vesz igénybe, mint maga a fejlesztés.  

Az agilitás 5 erénye

agilitás erénye

De ne ragadjunk le a negatívumoknál. Vannak szervezetek, akiknél jelentős javulást hozott az agilis transzformáció, vagy azért, mert ésszel nyúltak hozzá, vagy azért, mert jellemző működésükre jobban illettek az agilis elemek. Az agilitás alapértékei rengeteg pozitívumot is hoztak, amik reméljük, sokáig velünk maradnak, bármely módszertannal nyúlunk a fejlesztésekhez. 

  • Javította az üzlet és az IT együttműködését – azoknál a cégeknél, akiknél az üzleti területek is részeivé váltak az agilis csapatoknak. Ahol ezt nem tapasztalod:  a tisztán delivery csapatoknál, ahol a Product Owner nem üzleti ember, ott ez a hatás nem érvényesült.  
  • Egyértelműen definiálja a tervezési szinteket: epic/feature, story, A/C. Kézzelfoghatóvá teszi a progressive elaboration (fokozatos lebontás) elvét. Ahol ezt nem tapasztalod:  sajnos kevés helyen használják jól. Sok helyen nem értik a teljes tervezési (design) folyamatot – a koncepcionális tervezést és az üzleti designt (sok helyen a technikai designt is)  átugorva, egy homályos üzleti elképzelésből definiálnak fejlesztési feladatokat. 
  • Bevezette az üzleti érték fogalmát: bár sokszor rosszul használják, de az kétségtelen tény, hogy az utóbbi években már a felesleges és értéktelen funkciók száma mérséklődött. Egyszerűen nem jut ilyenre már idő, örülnek a cégek, ha a szükséges minimum funkciók leszállítódnak.  
  • Megtanította a feladatok kapacitáshoz igazítását: paradoxon, de a szállítás lassulásának egyik oka az, hogy túl sok a befogadott igény, több, mint a rendelkezésre álló kapacitás. Az agilitás folyamatai (sprint planning, PI planning) – remek eszközöket biztosítanak a kapacitás mérésére és tervezésére. Ahol ezt nem tapasztalod:  ahol nem veszik figyelembe a kapacitást, és 130%-ra terveznek; ahol a tervezés ellenére mégsem állnak rendelkezésre az erőforrások;  illetve ahol befigyel a határidő is, ott már nem működnek a tankönyvi technikák, ott már gondolkodni kell. 
  • Megtanított darabolni:  ez is egy olyan előny, amit ritkán látok jól használni, bár lehetne: az üzleti érték mentén történő darabolás. A legtöbb esetben a csapatok architekturálisan vagy kompetencia alapon kezdenek darabolni (pl. először lefejlesztik a képernyőket – az összeset.) De mivel a backend és az üzleti folyamatok hiányoznak mögülük, ez – bár látványos és mutogatható – nem jelent üzleti értéket a cég számára. 
agilis folyamat

Összegzés

Összességében azt gondolom, hogy nem a módszertannal van a hiba, hanem annak alkalmazásával – a bevezetéskor nem veszik figyelembe a cégnél jellemző működést, feladatméreteket, összefüggéseket. Ezekben az esetekben a transzformáció drága és kontraproduktív.

Figyelembe kell venni, hogy a nagyvállalatoknak nem rendszerekben gondolkoznak, hanem üzleti folyamatokban – egy-egy üzleti folyamatot számos rendszer támogat, amit egy-egy felmerült üzleti igény kapcsán változtatni kell. A kialakított működésnek attól kellene függnie, hogy a projekt és fejlesztési portfólióban milyen típusú feladatok vannak jellemzően.

Ennek ismeretében lenne érdemes kiválogatni és összerakni a klasszikus és agilis elemeket, egy működtethető hibrid megoldást hozva létre.  

Projektcoach – a hibrid megoldások szakértője 

Hibrid projektek vezetése és kihívásai: hogyan rakd össze az elefántot?

Agilisan működő nagyvállalatoknál scope-pal és határidővel rendelkező nagy és komplex feladatok megvalósítása esetén egyre többször kell a klasszikus projektmenedzsment eszközeihez visszanyúlni, az egyes elemeket kombinálni. De hogy érdemes ezt jól csinálni, hogy az készüljön el, és akkorra, amire szükség van, és az agilitás előnyeit se veszítsük el?
Kattints ide

agilis transzformációagilitás