Korábban arról írtunk, az agilis módszertanra való átállás látszólag nem túlságosan nehéz feladat. Ha a szolgáltató már egyébként is érdekelt az állandó szolgáltatásfejlesztésben (Continual Service Improvement, CSI), akkor az agilis szolgáltatásmenedzsment bevezetése gyakorlatilag a következő, természetes lépcsőfokot jelenti. Nagyon könnyű azonban a szemléletváltást technikai váltások sorozatává degradálni, aminek egyenes következménye lesz, hogy az elvárások nem teljesülnek. Mit lehet és mit kell tenni ennek elkerüléséhez?

Célok és szerepkörök

A hagyományos projektvezetéshez képest (talán meglepő módon) nincs túl sok különbség az előkészületeket illetően. Az általános lista itt is sorolható: a szervezetnek elő kell készítenie a projektcsapatot a szerepek és felelősségkörök meghatározásával és szétválasztásával együtt. Ez időráfordítással is jár. A projekt időszakát be kell határolni és a csapattagokat elérhetővé tenni, hogy hatékonyan és ténylegesen tudjanak részt venni a projektben – ami azzal is jár, hogy kiesnek a mindennapi feladataik elvégzéséből.

Természetesen a projekt céljait is előre meg kell határozni. A csapaton túlmenően szükséges úgynevezett stakeholderek bevonása – az ő feladatuk az, hogy képviseljék a szervezet igényeit, elvárásait .

Ami ténylegesen különbözik egy agilis projektszervezésben, az például a product owneri (PO) szerep, melyet már a kezdet kezdetén meg kell határozni. A PO feladata hasonló, mint a hagyományos modellekben a projektmenedzseré: biztosítania kell, hogy a csapat tudja, mikor mit kell tennie. Ezzel el is jutunk egy másik nélkülözhetetlen agilis projektelemhez: a backloghoz, amely a projekt során elvégzendő feladatok listája. Ennek priorizálása a PO dolga, fontos viszont megjegyezni, hogy a prioritás a projekt során változhat, foglalta össze Béres Boróka, a TOPdesk tanácsadója.

Könnyű elbukni

Az agilis módszertan alkalmazása önmagában nem hoz sem káoszt, sem megoldást. Az egyik fő érv mellette, hogy hamar tud eredményeket felmutatni, ám első próbálkozások alkalmával gyakran ennek épp az ellenkezője történhet. A vezetés elkötelezettségének hiánya, a fejlődés sürgető késztetésére való érzéketlenség, a változással szembeni ellenállás könnyen eredményezheti azt, hogy a módszertan alkalmazását követően a vállalat hamarosan visszatér az eredeti status quo-hoz.

A probléma egyik gyökere, hogy a bevezetést elhatározók és végrehajtók hajlamosak úgy tekinteni a feladatra, mintha az egy szoftveres/hardveres upgrade lenne. Ugyanakkor, míg például egy levelezőszerver-frissítés valóban csupán technikai jellegű átállást jelent, az agilis módszertannál a műszaki változások nem a fő csapásirányt jelentik, hanem csak a szemléletváltás hozadékaként jelentkeznek. Eleve hibás az az elképzelés tehát, ami a műszaki eljárások lépésről lépésre történő bevezetésével próbál hatékonyságnövekedést elérni; ehelyett inkább olyan kérdéseket kell feltenni (és megválaszolni), mint például mit is akarunk elérni hosszútávon? Vagy: hogyan lehet az ügyfelek igényeit jobban kielégíteni?

Ettől függetlenül fontos a felmutatható eredményekre koncentrálni, valós szervezeti igények megoldásait célul kitűzni. Ez egy implementáció esetében például megnyilvánulhat egy szakaszokra felosztott élesindulás formájában, amely egyben biztosítja a kezdetektől a folyamatos felhasználói visszajelzéseket is. Ha azonban az agilis módszertan bevezetésének folyamata nem biztosítja az alkalmazott folyamatok és a partnerek jobb kiszolgálása közötti kapcsolatot, akkor az átállástól várt eredmények – legyenek azok akár ROI ( Return On Investment – a befektetés megtérülésének mutatója) formájában számszerűsítve – sem fognak az elvártnak megfelelően alakulni.

Megfelelő megvalósítás esetén az agilis módszertanra való átállás nagy motivációs hatást gyakorol a benne részt vevőkre. A motiváció és az ennek munkahelyi morálra tett hatása pedig jóval hatékonyabbá teszi a munkavégzés teljesítményét.

Mi történik siker esetén?

Az agilis módszertan által kikényszerített folyamatos értékteremtés és visszajelzés révén jelentősen felgyorsulhat az ügyféligények kielégítése, ami a korai adaptáció lehetősége mellett a partnerkapcsolatok javításában is komoly szerepet játszik. Mivel ügyfélközpontú módszerről van szó, ezért a hangsúly a műszaki jellemzők helyett az üzleti értékekre kerül, ez az érdekeltek csoportmunkába vonásával együtt a partnerre fókuszáló keretet biztosít a feladatvégzésnek.

Amint említettük, számos ITSM (IT Service Management) projekt elbukásához hozzájárult már, hogy a szervezetek a projekt "lezárását" követően apránként visszatértek a korábbi állapotba. Ennek ellenszere a nyitott backlog; a Scrum a CSI-hoz hasonlóan lehetővé teszi a folyamatos feladatkiadást vagy azok újragondolását, annak tükrében, hogy mit is akar az adott szervezet elérni. Hatékonyságát nagyban növelheti az állapotjelzők transzparens mivolta, vagyis a szükséges információk megosztott, könnyen áttekinthető helyzete.

Noha könnyű megérteni az agilis módszertan működését, az alkalmazás nagyobb kihívást jelent. Hatékony Scrum alkalmazásához magas szintű önszerveződő képességre van szükség, ami érett vállalati hierarchiát és a személyes felelősség elismerésének magas szintjét igényli. Nem meglepő, hogy az átállás elején gyakran többször szembe kell nézni a kudarcélménnyel, ezek a negatív visszacsatolások azonban fontosak a fejlődés szempontjából. Ennek köszönhetően – elegendő elkötelezettség esetén – előbb-utóbb létrejön a szemléletváltás a teljes szervezetben, és megvalósul az agilis módszertan alkalmazása.