Kislányom születése épp egybeesett a konferencia időpontjával, így én is reagáltam a változásra: a konferencia helyett a szülőszobán küzdöttem. A konferencia egyik kiemelt témáját, az agilitást, illetve a szemlélet helyét a nagyvállalatban, fontosnak és aktuálisnak érzem, így írásba foglaltam saját, a A CIO-k elmondták, hogy alkalmazható az agilitás egy nagyvállalatnál című cikk végkicsengésétől némileg eltérő tapasztalataimat.

2016 óta foglalkozom mélyebben az agilitással és a lean témakörével. Nem vagyok coach, nem láttam ezer szervezet mély agilis működését, de havonta elolvasok legalább egy-két könyvet a témában, és próbálom az agilis transzformációt minden eszközzel támogatni a Lechner Tudásközpontban. Agilis szponzorként saját bőrömön tapasztalom meg hatásait: a produktivitás drasztikus javulását, a fluktuáció minimalizálását, a munkatársak és a felhasználók elégedettségének növekedését egyaránt.

Olyan komplex digitális termékeket fejlesztünk agilis módszertan (scrum, kanban) alkalmazásával, melyeken 300 fő (belsős és külsős) munkálkodik naponta, havonta pedig mintegy fél millió ember használ jelenleg is ezeket. Összefoglaló nevén ez a digitális építésügy.

Agile is a journey

Magam is tapasztaltam, hogy valóban létezik az a várakozás, hogy az agilitás gyógyír a sebekre: ha bevezetjük, akkor többet és korábban szállítunk, hatékonyabban fejlesztünk, és tervezhetőbben adunk át termékeket. Azt gondolom azonban, hogy érdemes súlyozni az előnyöket. Inkább van szükség jobb termékre és elégedettebb felhasználóra – amivel természetesen nagyobb profitra tehetünk szert –, mint hatékonyabban szoftverfejlesztésre.

Valójában az agilitás szervezetfejlesztési kérdés, amely egyébként hatékonyabb szoftverfejlesztést is eredményez, de nem az a lényeg. Sokkal fontosabbnak érzem azokat a kulturális változásokat, amelynek eredményeként a tehetségek kiemelkedhetnek, drasztikusan javul az együttműködés, természetes lesz a felelősségvállalás, a csapatszellem pedig hasonló, mint egy jól működő családban. Egy igazi agilis szervezetben a munkatársak reggelente szívesen pittyentik le a beléptető kártyájukat, azt érzik, hogy hónapról hónapra fejlődnek, és az ennek közösen tudnak örülni. Egy ilyen szervezet az értékekre fókuszál, a munkatárs és a végfelhasználó egyaránt középpontban van.

Sajnos itthon nem sokan veszik komolyan az agilis kiáltvány első mondatát: "A szoftverfejlesztés jobb módjait tárjuk fel saját tevékenységünk és a másoknak nyújtott segítség útján." Alig-alig találtam olyan hiteles community-t, szakmai fórumot, ahol hiteles információt kaphatnék a témáról. Ellenben ömlenek a különféle buzzwordökkel hirdetett konferenciák, melyek többségén az agilis is egy hashtag a felhőben, és pont annyit tudunk meg a téma igazi mélységéről, mint a cloud, a big data vagy smart city valódi tartalmáról.

A CIO Hungary wokshopjáról született cikk egyfajta összegzése – ezáltal a szükségszerűen egyszerűsítése – sok egyéni véleménynek, tapasztalatnak. Úgy gondolom azonban, hogy a cikknek van néhány olyan megállapítása, amivel érdemes vitába szállni. Az alábbiakban ezeket veszem sorra.

A reakció

'Szintén nem tartotta jó ötletnek a többség az üzletkritikus rendszerek agilis fejlesztését, ahogy a nem agilisan fejlesztett rendszerek agilis továbbfejlesztését sem" – írja a fent idézett cikk.

Érdekes példa lehet ez esetben a NASA, az amerikai Nemzeti Repülési és Űrhajózási Hivatal. Azt biztosan mindenki elfogadja, hogy a NASA tevékenysége "üzletkritikus". Az űrséta nem játék, rengeteg pénz és az űrhajósok élete múlik a jó szervezésen. A NASA a 80-as évek óta kizárólag iteratív, agilis fejlesztési módszertan [PDF] alapján indít termékfejlesztést, ráadásul ez szigorú szabály, más módszertant tilos követni.

Általános vélekedés volt a résztvevők között, hogy üzemeltelést és supportot nem érdemes agilisan végezni. Itt a már kialakult folyamatok megbolygatását a többség nem érezte indokoltnak.

Az "agilis" voltaképpen egy gyűjtőfogalom. Van például olyan agilis módszertant, ami kifejezetten az üzemeltetés támogatására használható, például a kanban. Olyan üzemeltetéssel és supporttal foglalkozó cégek használják ezt, mint az AWS (Amazon web Services), a Microsoft, a Nokia vagy az IBM, hogy csak néhányat említsek. Úgy vélem, nem a specifikus szakterület határozza meg, hogy van-e helye az agilitás egy válfajának, hanem sokkal inkább a szervezet kultúrája. Minden az emberen, a közreműködőkön múlik.

Minden szervezetben kiemelt célnak kellene lennie a kialakult folyamatok folyamatos fejlesztésének, hogy a szervezet képes legyen reagálni a folyamatosan változó környezetre. Kevés olyan céget tudnék mondani, ahol tíz éve ugyanazon alapfolyamatok működnek, és azokon semmit sem kellett változtatni a piaci részesedés megtartásáért vagy esetleges növeléséért.

A közbeszerzéses projektek maradtak a tiltólista végére: általános a vélekedés, miszerint az emberiség még nem találta fel azt a dimenziókaput, amivel a közbeszerzések és az agilitás világa átjárhatóvá válna.

Közbeszerzésre kötelezett szervezet képviselőjeként, közbeszerzések részvevőjeként ezzel is vitatkoznék. Hozok azonban külső példát. A U.S. Digital Service Agency-t (DSA) 2014 augusztusában hozta létre az amerikai elnök, Barack Obama. Mára az ügynökségnek több ezer tagja van a közigazgatásban egészségügyi, oktatási, honvédelmi, valamint gazdálkodási területekről. Több mint kétszáz online szolgáltatás indult a DSA támogatásával és felügyelete alatt, kezdve a beszerzéstől az üzemeltetésre való átadásig. Közös bennük, hogy agilis módszertant használtak a termékek fejlesztése során.

Ez azonban nem csak amerikai sajátosság. Kanadában 2018 elején adtak ki egy rendeleti kezdeményezést az agilis közbeszerzésről. És hogy európai példát is említsek: a sokszor itthon is mintaként említett észt e-közigazgatás rendőrségi rendszerének fejlesztése szintén tisztán agilis alapokon készült.

Hazánkban is van már gyakorlat arra, hogy közbeszerzési területen vessék be az agilitást. 2017 októbere óta (a brit, svéd és amerikai példa után) fut a Lechner Tudásközpont jegyzésében a digitális építésügy megújítását célzó projekt is ezt a módszertant alkalmazta. A projekt egyébként közbeszerzési értelemben már lefutott. Jelenleg az alkalmazásfejlesztési feladatok folynak.

Gyakori és végzetes hiba a tervezés elhanyagolása. Ez rávilágít az egyik alapvető tévhitre: az agilitással feleslegessé teszi a hosszú távú és magas szintű tervezést.

Both András
CIO, Lechner Tudásközpont

Gazdaságinformatikusként végzett a Budapesti Corvinus Egyetemen. Az egyetem után magas rendelkezésre állású közösségi oldalakat fejlesztő cégeknél alkalmazásfejlesztőként, majd projektmenedzserként dolgozott. Később társalapítóként vezette egy digitális termékfejlesztéssel foglalkozó digitális ügynökség munkáját. 2015. óta a Lechner Tudásközpont informatikai igazgatóságát vezeti, amely a elektronikus építésügyi működtetési és továbbfejlesztési feladatait látja el.

Ez a tévhit valóban létezik, de érdemes kicsit bővebben kifejteni a problémakört. Az agilis módszertan elvileg folyamatosan és több szinten tervez. A gyakorlat sokszor mégsem ez, és amikor jelentkeznek a problémák, azokat közösen ráfogjuk a módszertani hiányosságra. Pedig az agilis módszertan nagyon is foglalkozik a tervezési részletekkel. Kétségtelen, hogy az agilis tervezés öt szintjét (vízió, roadmap, release, iteráció és napi tervezés) nehéz jól elsajátítani, és talán még nehezebb bevezetni (de vajon egyszerű például megtanulni jó kódot írni vagy felkészülni a GDPR-ra?)

Ugyanakkor az agilis témakörön belül léteznek olyan megalapozó követelményelemzési technikák, melyek könnyen használhatók a termékfejlesztés kezdő lépéseinél és  később is. Az egyik ilyen – egyébként általunk is használt – módszer a lean inception, melynek segítségével már több mint 15 országos rendszer tervezésén vagyunk túl a Lechner Tudásközpontban, és szerénytelenség nélkül állíthatom, magunk is csak bámulunk az eredményén.

Az agilitás egy általánosan elfogadott eszközzel bővítette az IT-vezetők eszköztárát.

Ez sarkalatos kérdés. Ha úgy tekintünk az agilitásra, hogy egy eszköz az IT-eszköztárunk bővítésére, akkor nem sokat nyerhetünk általa. Hadd utaljak vissza a bevezetőben írottakra: az agilitás egy gondolkodásmód, ami éppen felfalja a világot Persze az opcionális, hogy valaki a túlélést választja, vagy sem.

A legnagyobb kockázat

Az agilis bevezetésének legnagyobb gátja és kockázata a tanulni és változni nem akarás. A dacos hajtogatása az általunk már jól ismertnek és rutinból használtnak.

Folyamatosan csapnak össze az új technológiák a régebbiekkel, de ez nemcsak szoftveres vagy hardveres technológiák közdelme, hanem kulturáké is. Mindset, értékek, leadership és értékalapú hozzáállás – mostanság épp ezek az “új” praktikák. Egyáltalán nem mindegy, hogyan tekintünk ezekre az újdonságokra, ám merészségre mindenképpen szükség van ahhoz, hogy kipróbáljuk őket.