Bár az idei CIO Hungary konferencián – miután több mint 15 év nagyvállalati IT-vezetői munka után más irányba vitt az élet – nem vettem részt, érdeklődve olvastam konferenciáról született beszámolókat. Köztük különösen az a cikk vívta ki figyelmemet, amely a nagyvállalati agilitás témáját körüljáró workshop megállapításait foglalta össze (A CIO-k elmondták, hogyan alkalmazható az agilitás egy nagyvállalatnál). Úgy vélem a workshop jól leképezte azt, hogy milyen az agilis metodológiák itthoni megítélése ma ebben a közegben.

A téma fontosságát jelzi, hogy az összefoglalóra már született egy hozzászólás Both Andrástól, a Lechner Tudásközpont CIO-jától (Különvélemény az agilitásról). Az alábbiakban én is ezt a vitát szeretném folytatni, remélve, hogy más is kedvet kap véleménye megosztására.

Kivételek – más nézőpontból

Az elmúlt bő egy év alatt projektportfólió-tanácsadóként és agilitási coach-ként dolgoztam, így volt alkalmam más nézőpontból is elmélyülni a témában. Az így szerzett tudásomat szeretném ütköztetni korábbi, CIO-ként szerzett saját tapasztalataimmal és a volt kollégáim véleményét összefoglaló cikkekkel.

Az első, ami megütötte a szemem, hogy az összegyűjtött tapasztalatok magyaros "optimizmussal" úgy lettek kivételekre és jó példákra bontva, hogy a mérleg erőteljesen az előbbiek felé billent, mintha abban próbálnánk megerősíteni magunkat, hogy miért nem akarunk agilis szervezetet. Az alábbiakban Both Andráshoz csatlakoznék, és pozitív példákkal erősíteném meg a metodológiával kacérkodó nagyvállalati informatikai vezetőket. A sikerhez ugyanis az is kell, hogy a szervezete pozitívan álljon az agilitás bevezetéséhez.

A workshopot moderáló Tanács Lajos összefoglalójából kiderült, hogy a kivételek egyik legplasztikusabb esete – ahol nem lehet alkalmazni az agilitást – az úgy nevezett "hídépítés" jellegű projekt. Hiába szakaszolt a végrehajtás, azzal mit sem nyerünk – állítják az agilitás ellenzői –, hiszen a korai szakaszokban, amikor az ívek két vége még nem ér össze, a híd használhatatlan.

De nézzük meg a kérdést más nézőpontból! Kétségtelen, hogy a híd hasonlat érzékletes, ám eltereli a figyelmet az agilitás két legfontosabb lehetőségéről. Először is arról, hogy a rövid szakaszokra osztott megvalósítás fő haszna az, hogy kis csomagokban lehet kidolgozni és ellenőrizni az előrehaladást. És ez még akkor is igaz, ha ezek a sprintek nem feltétlenül kerülhetnek egyesével használatba.

Másrészt a hasonlat nem veszi figyelembe az agilis módszertanok által javasolt – és Both András által is propagál – legkisebb életképes termék (MVP – Minimum Viable Product) elvet. Pedig ezzel elkerülhető lenne az jó kelet-európai hiba, hogy a hidak végtelenségig való cicomázása miatt kell többször elhalasztani az átadást, miközben azok jól definiált MVP esetén már rég használhatók lennének.

Nehéz vitatkozni a közbeszerzéshez kötött projektek teljesen agilisként kezelhetetlenségével, bár Both András vitacikkében egy sor példát hoz olyan országokra, ahol ezt igenis sikerült megvalósítani. Én azonban más szempontból árnyalnám a problémát.

Nem mindegy, hogy a Közbeszerzési Eljárást elváró hardveres infrastruktúra vagy akár a kezdeti szoftverfejlesztés mellett hogyan nyúlunk a rendszerhez a továbbiakban. A kulcs ezek esetében egyrészt az, hogy a közbeszerzés kiírásakor az elvárások közé fel kell venni a későbbi agilitást támogató elemeket, például a DevOps megközelítést vagy az automatikus regressziós tesztelés felállítását, a rendszerfunkciók és felhasználói sztorik mentén strukturált rendszerdokumentációt stb. Másrészt, ha a kezdeti munka alatt stratégiai partnerség is kialakul a szoftver-beszállító és a megrendelő között – remélhetőleg igen –, akkor gondos metodológiával elválasztott felelősségek mellett lehetséges akár nem agilisan fejlesztett szoftverek agilis továbbfejlesztése is.

A "megcsontosodás" problémája

A legnagyobb csapdának azonban azt látom, amikor azzal kampányolnak az agilitás ellen, hogy az – főleg üzletkritikus rendszereknél – veszélyezteti a jól működő folyamatokat, a kialakult üzletmenetet. Erről mindig az jut eszembe, hogy talán hasonlóan gondolkodtak a Kodak (isten nyugosztalja) vezetői is, amikor elkezdett terjedni a digitális fényképezés. Egyre nyilvánvalóbb, hogy ezt a fajta hozzáállást egyre kevesebb tradicionális iparág engedheti meg magának. Teljesen tiszta jövőkép, világos vízió megfogalmazására manapság kevesek várhatnak a végtelenségig, ezért is elengedhetetlen mielőbb nekilátni az agilis transzformációnak –  már ha szeretnének egy jó eséllyel hamarosan a feje tetejére álló iparágban a jövőben is labdába rúgni.

Ilyen szintű transzformáció természetesen nem indítható csak a vállalat IT-szervezete, de csak egy üzleti területen se. Jó alapot ad, ha az informatikával szemben a cégben korábban olyan bizalom alakult ki, hogy minden érintett alkalmas partnert lát benne a digitális megújulás folyamatában. Ez megteremti annak lehetőségét, hogy az IT kiemelt szerepet kapjon, de sikerhez elengedhetetlen a teljes vezetés „megvilágosodása” és elkötelezettsége, és persze a HR aktív támogatása is kell az új szervezeti működési modell kidolgozásához (például teljes időben összeálló kereszt-funkcionális scrum-csapatok felállítása).

Az agilis transzformáció a hosszú távú tervezés átalakítását is igényli, hiszen az agilis metodológiák részletesen csak a megkezdett projektszakaszok elején terveztetik meg a megoldásokat, viszont azt magas szinten és előre el kell dönteni, hogy melyik stratégiai irányra mennyi erőforrást szán a cég.

Agilitás a részben és az egészben

Ha mindez összeállt, még közel sem jutottunk el a problémákat megoldó általános mesterkulcshoz. A következő kihívással legtöbbször akkor szembesülnünk, amikor kiderül, hogy a csúcsvezetői szinten megfogalmazott stratégiai célokat a csapatok nem tudják operatív kezdeményezésekre lebontani. És a dolgoknak van egy másik iránya is: a felső vezetés nem látja, hogy az elvégzett csapatfeladatok összességükben hogyan járulnak hozzá a stratégiai célok eléréséhez.

Takács István Péter

A szerző gazdasági informatikus. Pályáját tanácsadóként kezdte az Accenture-nél, majd több nemzetközi cégnél töltött be vezető pozíciót IT-területen. Tizenegy évig dolgozott az E.ON-nál többek között üzletági CIO-ként és más informatikai vezetői szerepekben. Jelenleg a Capture Zrt. régiós tanácsadója.

Erre a legtöbb, csapatszinten használt agilis metodológia nem ad támogatást. Van azonban egy viszonylag friss, épp erre a helyzetre alkalmazható módszertan, az amerikai fejlesztésű Scaled Agile Framework (SAFe). A SAFe támogatja a stratégia fejlesztési értékláncok (development value streams) meghatározását, azok priorizált fejlesztési történetekkel (epics) történő feltöltését, és optimális összetételű, „élesítési-vonatokra” (Agile Release Train) ültetett agilis csapatoknak történő felosztását.

A módszertan kipróbálható egy-egy értékláncon is, de mindenképpen az operatív szinttől a felső vezetésig bezáróan be kell vezetni, hiszen előnyei pont a két szint összekapcsolásában mutatkoznak meg. Ha már egy-két értékláncnál jól működik, a SAFe segít a skálázásban, hogy nagyobb szervezeti egységekre, termékvonalakra is kiterjeszthessük, míg végül a teljes cég átáll az agilis működésre.

Ezt a módszertant talán egyedüliként támogató szoftver a Computer Associates terméke az Agile Central- (CA-AC), melyet munkámból adódóan ismerek alaposabban (itt fontosnak tartom megjegyezni, hogy jelenleg én is a terméket a régióban támogató Capture Zrt.-nél dolgozom). A CA-AC az operatív agilis munkához is jól használható, de az eredményeket folyamatosan strukturált módon összegzi az agilis szervezet magasabb szintjein is, ami  javítja az előrehaladás vállalati szintű transzparenciáját.

De a CA-AC csak segédeszköz. A SAFe – ahogy minden módszertan – használható, bevezethető célszoftveres támogatás nélkül is, sőt maga a SAFe sem az egyetlen üdvözítő út ahhoz, hogy egy szervezetet átfogóan agilissá alakítsunk. De egy nagy szervezet esetén valamiféle módszerre mindenképpen szükség van, hogy az üzleti területek érettségüknek megfelelően be tudjanak kapcsolódni a folyamatba, és végig is jussanak ezen az úton. Ebben egy jól megválasztott eszközzel sokat könnyíthetünk: nemcsak a napi aprómunkán, hanem azáltal is, hogy folyamatosan az agilis megközelítések felé irányítja használóit.