Agilitás jelentése – Cél vagy eszköz? Ha eszköz, mit kezdünk vele?

Az agilitás jelentése erősen függ a kontextustól

Az agilitáss jelentése lehet szemlélet, cél, módszertan, tulajdonság vagy akár szervezeti modell is. Az agilis jelentéséről egy korábbi cikkünkben foglalkoztunk bővebben.

Miért akarunk agilis szervezet lenni? Mit szeretnénk vele elérni?  Ez az első kérdés, ahol megakad a kommunikáció. Ugyanis ahány cég, annyi válasz, ha van egyáltalán kimondott cél. A tipikus, félinformációkra és tévhitekre építő indokokkal (nem tervezgetni kell, hanem csinálni, bármikor lehet változtatni, nem kell dokumentálni,stb.) most nem szeretnék foglalkozni, inkább a valós kérdésekre érdemes fókuszálni. Nézzük, mik ezek, az agilitás mennyiben lehet a jó megoldás, illetve milyen alternatívák léteznek.

Probléma 1: Nem működik az IT és az üzlet között a kommunikáció – Cél 1.: Az IT és üzlet közti kommunikáció javítása

Agilis PRO: tény, hogy ha betartjuk az agilis alapelveket (napi kommunikáció, napi 8 órás együttlét, 100%-ban feladathoz rendelt emberek), jelentősen javíthatjuk a kommunikációt és az együttműködést a team tagjai között. Ha a feladat jellege és a team összetétele megengedi, a kellő felhatalmazás rendelkezésre áll, az agilitás erre a problémára megoldást jelenthet.

Agilis KONTRA: az a kérdés, kit nevezünk üzletnek. A klasszikus agilis felfogásban az az üzlet = ügyfél, illetve az üzlet az ügyfelet képviseli. Egy nagy szervezetben az üzlet = nem IT, tehát ide soroljuk a szakmai, illetve háttérterületeket is. A projektek által generált változások legtöbbször több üzleti/szakmai területet érintenek. Tehát egy számviteles, vagy kontrollingos, esetleg HR-es munkatárs minden projektben szükséges lenne, de sokszor nem igényel 100%-os jelenlétet.

Igen-igen, tudom, a disznók és a csirkék. Mivel dolgoztam ilyen munkakörben, lehet, hogy szerepzavarosként, de sosem éreztem csirkének magam. A felsővezetésnek jelentve, a NAV által fenyegetve, csöppet sem mindegy, hogy egy projekt mennyire trollkodja szét pl. a jól felépített adatszolgáltatási/számviteli/elszámolási, stb. folyamatokat. Ebből a szempontból ők is ugyanolyan disznók, akik a „sonkájukat” viszik a vásárra, csak éppen az összes futó projekt által érintve…Ebben az esetben viszont, amennyiben nem sikerül olyan kollégát minden csapatba beültetni, aki 100%-ban ott van, és képes átlátni az adott szakterület teljes vertikumát, ugyanúgy lehetnek problémák a kommunikációval, sőt.

ALTERNATÍVA: akár agilis, akár hagyományos vagy kevert munkamódszerrel dolgozunk, egy jól képzett üzleti elemző segít feloldani és összehangolni az ellentmondásokat, és megtalálni a jó megoldásokat. Az üzleti elemzés képes áthidalni a kommunikációs szakadékokat, és lefordítani a kapott információkat követelményekké, vagy user storykká. A modern megközelítésekben ezek már csak formailag térnek el egymástól.

Probléma 2.: Hosszú a leszállítási idő – Cél 2: Time to market rövidítése

Agilis PRO: amennyiben a termék felbontható önállóan is implementálható részekre, az agilitás jó alternatíva. Szintén erősen ajánlható olyan esetekben, amikor a létrehozandó produktum mindenképpen új értéket képvisel a szervezet számára (új termék, új funkciók). A leszállított részek tesztelhetők akár felhasználók, akár a piac fogadtatása szempontjából. A tévutak gyorsan észrevehetők, korrigálhatók.

Agilis KONTRA: ha a termék nem új, hanem pl. egy meglévő rendszer cseréje, ott nehezen lehet részletekben implementálni, ebben az esetben az agilitás nem rövidíti a leszállítási időt (sőt). Az új rendszernek a meglévő funkcionalitást biztosítania kell, lehetőleg hatékonyabban, mint a régi, csak ez után beszélhetünk új üzleti funkciók hozzáadásáról.  Ez viszont azt jelenti, hogy az első értelmezhető, önállóan implementálható rész (MVP) a meglévő (használt) funkcionalitás biztosítása (kényszer hatására persze ebből lejjebb lehet adni, de ez biztos, hogy nem növeli a felhasználói elégedettséget ?). Azt, hogy működik-e a rendszer, akkor derül ki, amikor integrált környezetbe helyezzük a terméket, valószínűleg a projekt legvégén. És akkor még nem említettük azokat a feladatokat, amik nem a rendszerhez kapcsolódnak: egy tökéletes rendszer is simán elhasalhat az adatminőségen, ha az kívül esett a team hatáskörén…

Az pedig ma már alap, hogy ami elkészült, azt mutogatom a felhasználóknak, ezt már vétek az agilitáshoz kötni.

ALTERNATÍVA: ha nem bontható fel a fejlesztés önállóan is implementálható részekre, akkor érdemes kombinálni a módszereket. A Minimum Viable Product (legkisebb életképes termék, ami új termék esetén – leegyszerűsítve – az első, minimálisan életképes piaci verzió, csere esetén pedig a már meglévő – felhasználók/ügyfelek által használt = értéket jelentő -üzleti funkcionalitás biztosítása) leszállítása tervezetten, üzleti elemzésre épülve (környezettel, az érintettek követelményeivel összehangolva, a teljes körűség biztosításával) kell, hogy megvalósuljon. Ez több időt vesz igénybe, és más módszereket (is) igényel.

Probléma 3.:  nem szállítunk elég üzleti értéket, nem az üzletileg fontos dolgokra mennek el az erőforrások – Cél 3.: üzletileg nagyobb értéket szállítani

(Sajnos ezt a célt hallom legritkábban, pedig -szerintem- az agilitásnak a legfontosabb üzenete)

Agilis PRO: Az agilitás egyik legeredetibb gondolata az, hogy az ügyfél számára legfontosabb (legnagyobb értéket jelentő) funkciókat szállítsuk le legelőször. Ha ezeket könnyű beazonosítani, illetve a team képes/felhatalmazott a szükséges döntéseket, kompromisszumokat meghozni, nosza, legyünk agilisak! Az ügyfelet a Product Owner képviseli.

Agilis KONTRA: Oké, de ki az ügyfél? Csak egy ügyfél van? Ha fejlesztő cég vagyunk, akkor persze, az, aki aláírja a számlát a végén ? De ha mi is szolgáltatunk? Ugyanazt akarja a vezetőség, mint az ügyfél? Vagy a kontrolling? Vagy az IT biztonság? Képes/felhatalmazott/minden információnak birtokában van-e a Product Owner és a team arra, hogy pl. jó kompromisszumokat kössön pl. az üzleti növekedés – kockázatoptimalizálás tekintetében? Megfelelően tudjuk-e mérlegelni a lehetőségeket-korlátokat? Tapasztalataink szerint a scope creep jó nagy része a végrehajtási/szakértői szinten történik. Mi az az agilitásban, ami ezt megakadályozza? Mi a garancia arra,  hogy a Product Owner tényleg a vezetőség /és vagy az ügyfelek követelményeit, és nem a saját ötleteit valósíttatja meg?

ALTERNATÍVA: ÜZLETI ELEMZÉS! Nem a hagyományos értelemben vett – lejegyzetelem, mit mondanak, és szidom őket, hogy még arra sem képesek, hogy jól mondják meg a tutit – hanem a valódi, stratégiát ismerő, üzleti problémákat megérteni és elemezni képes üzleti elemzők által összegyűjtött, elemzett, teljeskörű és priorizált üzleti követelmények kellenek, amelyek közül kiszűrhetők és feloldhatók az ellentmondások. Az elemzés alapján kiszűrhetjük a kevés értéket /nagy ráfordítást igénylő követelményeket, meghatározhatjuk a Minimum Viable Product elemeit, fázisolhatjuk a fejlesztést. Viszont ebben a folyamatban sokszor kell majd dönte(t)ni, kompromisszumokat hozni a prioritásokról (mi a fontosabb, pl. be tudjuk tartani a határidőt, de van kisebb-nagyobb kockázata, vagy a megoldás által rövidebb lesz a ciklusidő, de ehhez fel kellene venni még 2 embert, de létszámstop van, és még sorolhatnám).

Probléma 4.:  Nem látjuk át, mivel foglalkozik a szervezet, mi hol tart – Cél 4.: Átláthatóvá tenni az IT leszállítást

Agilitás PRO: zseniális eszköze a Scrum módszertannak a „csőméret” nagyjábóli megmutatása, annak érdekében, hogy csak annyi feladatot indítsunk, amit képesek is vagyunk leszállítani. A beépített ellenőrző pontok, retrospektív-ek innentől arra szolgálnak, hogy folyamatosan növeljük ezt a leszállító képességet, amíg a team el nem éri a leszállítás maximumát.

Agilitás KONTRA: egy nagy szervezetben a fejlesztés csak a projekt egy része, és legtöbbször még csak nem is a szűk keresztmetszet (bár első ránézésre annak tűnik).  Hagyományos projektszemléletben (ami már rég nem a waterfall-t jelenti!) kb. a projekt felénél-utolsó harmadánál kezdődik a tényleges leszállítás fázis. Addigra tudjuk megmondani, hogy pontosan mire is lenne szükség. A szervezet leszállítási képessége nem ugyanaz, mint az IT leszállítási képessége. Tehát a szervezet leszállítási képességét kell monitorolni (projektportfólió management), és felfogni, hogy csak a leszállított projekt termel eredményt. Sok helyen persze már ezt is az agilitás részeként kezelik (a Scaled Agile frameworknek már része, Lean Portfolio Managementnek nevezik)

ALTERNATÍVA: jól működő, felsővezetés által támogatott Portfólió Management, ami a mérések és a folyamatos korrekciók használatával a szervezet leszállító képességének növelésén dolgozik. Segíti az átláthatóságot és a döntéshozatalt. A vezetőség felismeri, hogy a projektmenedzsment nevű játékot leszállításra játsszák. Partnerekké válnak, a projektmenedzsment környékén dolgozók pedig megtanulják, hogy a vezetőséget milyen információk érdeklik. Olyan anyagokat készítenek, amiből valódi döntéseket lehet meghozni. Ez sem könnyű, de nem nehezebb, mint egy agilis transzformáció ?

És ha idáig eljutottál az olvasásban, meghívlak egy kávéra, ha találkozunk ? És megírhatod, Te miért váltanál agilitásra?

Ha bővebben elmélyednél  agilitás jelentésében, gyere el Business Analyst módszertani és szemléletformáló képzésünkre, vagy egy Agilis Business Analyst gyakorlati napra!

» Az összes aktuális képzés >>