Szoftverfejlesztő területen korábban problémákat okozott a fejlesztések átláthatatlansága és tervezhetetlensége. Ugyanilyen gond volt, hogy nem tudtuk a munkatársaink teljesítményét objektíven vagy azt megközelítően mérni. Nagyon sokszor voltak újra visszatérő problémák a fejlesztésben, gyakran volt az az élmény, hogy a fejlesztők sokat dolgoznak, de ebből az ügyfelek semmit nem tapasztalnak, nem keletkezik érték, nincsenek a folyamatok befejezve.

Tulajdonosi igény is volt, hogy átláthatóbb legyen a fejlesztés működése, biztosak lehessenek abban, hogy a tervek, az ötletek a lehető legrövidebb idő alatt megvalósulnak, eredménnyé válnak. Nem a létszámot akartuk csökkenteni, hanem adott idő alatt több értéket szerettünk volna létrehozni.

Ezek a gondok olyan negatív élménnyé álltak össze, ami miatt elkezdtük keresni,hogy más fejlesztő cégek milyen módszerrel fejlesztenek és milyen arányban. A tavaly előtti Forrester jelentés szerint azon fejlesztő cégek közül, ahol használnak bármilyen módszertant, az agilis módszerek 80 százalék fölött vannak elterjedtségben, és ezen belül is a scrum fölényesen vezet, mint amit a legtöbben használnak, adaptálnak. Persze gyorsan adódik az a kérdés is, hogy akkor a többi agilis módszer miért nem jobb, vagy miért nem azt kezdik alkalmazni a cégek. A scrum „a módszertan nélküliségből az agilitás felé” illetve „a fegyelmezetlen és átláthatatlan működésből a fegyelmezett irányba” vezet. Tapasztalatom szerint a leghatékonyabban bevezethető módszertan. Nagyon fontos, hogy több adottsága van, több kötelezettség-vállalás van benne, mint más rendszerekben, amelyek többnyire csak néhány alapelvet határoznak meg.

A scrum egyik ígérete az, hogy adott idő alatt a lehető legmagasabb üzleti értéket hozza ki a fejlesztőkből, ez döntött mellette — mondja Emich. Megpróbáltuk saját tudásunkra alapozva bevezetni a scrum módszert, de sok kudarc ért bennünket. Szerencsére a vezetés ebből nem azt a következtetést vonta le, hogy a módszertannal van a hiba, hanem mi nem csinálunk valamit jól. Ekkor kerestük meg a Sprint Consultingot. Bár a Sprint Consulting fő ügyfélprofilja a multicégek magyar leányai és a külföldi tulajdonban levő cégek, a megkeresésünkre pozitívan reagáltak.

A bevezetést számos egyeztetés előzte meg, megvizsgáltuk hol tartunk, mik az adottságok, mennyi fejlesztőnk van, mit fejlesztünk, milyen technológiai módszereket alkalmazunk, milyen eszközöket használunk a projektek nyomon követésére. Az ajánlati fázis után a Sprint az összes scrumban résztvevő munkatársnak egy kétnapos tréninget tartott, ami a nemzetközi Scrum Master képzési anyagnak felelt meg. Az oktatás után következett egy iterációs szakasz, amikor lépésről-lépésre a scrum által előírt rendszeres meetingeket, eszköz használatot, és csapatfelosztást alakítottuk ki aSprinttel közösen. Ez a rész legalább annyira fontos volt mint az, hogy formálisan megismerjék a résztvevők a módszertant.

A legnagyobb szoftverfejlesztőknél is előfordul, hogy a megrendelt szoftver nem készül el időre, de jó esetben is gyakorta csúszik az átadás határideje. Az sem ritka, hogy a fejlesztést a csúszások ellenére is csak kompromisszumok árán lehetséges befejezni. Hiányozhatnak funkciók, elégtelen lehet a tesztelés. Átadáskor hibás lehet a program működése, és még a szerencsésebb projektek közé tartozik az, amelyik a tervezetnél nem lesz sokkal drágább, sorolja a teljesség igénye nélkül a negatív végkimeneteket Dr. Bodó Árpád Zsolt, a Sprint Consulting alapítója. Hozzátette, szerencsére van megoldás, még ha ez nem is mindig fájdalommentes.

A bevezetés természetesen számos konfliktust okozott onnantól kezdve, hogy azok, akik eddig a munkát koordinálták, nem találták a helyüket, hiszen ők általában projektmenedzserek voltak, és ők ebből a pozícióból valami más szerepkörbe kerültek — meséli Emich. A fejlesztők is kételkedtek a sikerben. Egész egyszerűen nem hitték el, hogy a menedzsment rájuk fogja bízni, hogy kézi vezérlés nélkül, szinte önszerveződő módon oldják meg a feladataikat. A vezetőségen belül is voltak konfliktusok, nehéz volt például elfogadtatni, hogy a szoftverfejlesztési ciklusok közben ne próbáljanak még újabb feladatokat kiosztani. Már az első tréningek alkalmával látszódott, hogy mind a két oldalon hiányzott a másik felé a bizalom, a hit, hogy ez jól fog működni. Azonban rövidesen már mindenki, a kollégák, a tulajdonos, a topmenedzsment is a bevezetés mellé állt, és akkor nagyon beindult a dolog — emlékezik az IT-vezető.

A szakirodalom szerint a bevezetés közben mindig eljön egy krízishullám – vagy akár több is – amit kezelni kell. Az Arkonnál is eljött. Magabiztosan bevezették a scrumot és úgy gondolták, ez után nincs is szükségük külső segítségre, mert anélkül is tudják, mit, hogyan kell csinálni. Csakhogy szép lassan jöttek a problémák, például a csapattagok elkezdtek megfeledkezni az elfogadási kritériumok fontosságáról, és kialakul egy belső ellenállás, lassan erodálódik az egész folyamat. Ezt mi is átéltük az ingatlan.com-nál — mondja Emich. A Sprint Consulting visszatért, és azóta is folyamatosan támogat minket. Biztos vagyok benne, hogy a mi környezetünkben sokkal többe kerülne, ha nem lennének itt.

Egyes iparági szakértők szerint a scrum módszerrel akár 300-400 százalékos teljesítmény-növekedést is el lehet érni. Mi ezt nem tapasztaltuk meg, igaz a Sprint Consulting nem is ígért ilyet. Amit ígértek, azt teljesítették: a kezdeti bevezetés óta, amikor elkezdtük a hatékonyságot mérni, legalább megduplázódott a fejlesztők teljesítménye — jelentette ki az Arkon szakembere.