Ahány ház, annyi agilitás

2019. 10. 10. | Fodor Andrea

Megpróbáltam összegyűjteni és szétválasztani, hányféle kontextusban hallottam már használni az agilitás kifejezést. Fontosnak éreztem rendszerezni, hogy mikor milyen aspektusról beszélünk, mit értünk alatta.  A lista a saját tapasztalatomat és értésemet tükrözi, nem teljes, örömmel venném, ha hozzászólnátok, kiegészítenétek!

 

Agilitás, mint szemléletmód:

Lean alapú szemlélet, ahol az vezérli a gondolkodást és a döntéshozatalt, hogy az ügyfél/vevő számára mi teremt értéket. Míg a Lean a munkafolyamatok hatékonyságára helyezi a hangsúlyt, az agilitás a termékek funkcióinak a vevő/ügyfél által elvárt értékből indul ki. Mindent mér, megfigyel, kicsiben kipróbál, értékel, és korrigál.

agilitás
Forrás: Pinterest

Mikor használható: Minden esetben. Ez módszertantól, szervezeti modelltől független gondolkodásmód. Business Analyst képzéseken is ezt a szemléletet oktatjuk, „vízesés” modellbe is könnyen beilleszthető. Ez mindennek az alapja, amíg e mellett a gondolkodásmód nem honosodik meg, nem érdemes következő szintre lépni.

Nehézsége: nagy szervezeteknél, főleg szolgáltató szektorban, az ügyfélen/vevőn kívül sok más tényező is meghatározza a működést. Figyelembe kell venni a tulajdonosok, jogszabályok, biztonsági követelmények által meghatározott kereteket. Sokszor kell kompromisszumokat kötni. Fontos viszont, hogy ez transzparens legyen.

 

Agilitás, mint cél

A menedzsment számára az agilitás annyit jelent, mint gyorsan, rugalmasan reagálni a piac elvárásaira. (Az egész agilis transzformációs hercehurcát ennek a célnak reményében vállalják.)

Mikor használható: elvileg bármikor, módszertantól, szervezeti formától függően lehet törekedni a gyors reagálásra, a leszállítás hatékonyabbá tételére. A reakcióidő a valóságban viszont nagy mértékben függ az üzleti és az IT architektúra bonyolultságától, a külső (jogszabályi) kötöttségektől.

Nehézsége: nem lehet szervezeti agilitásról beszélni, ha a kommunikáció nem az üzleti problémából és annak nagyságrendjéből, hanem az IT megoldásokból indul ki. Nem attól reagálunk jól a piac igényeire, ha különböző szoftvereket, applikációkat vezetünk be, hanem ha felismerjük a valódi igényt. Sokszor maga a menedzsment lassítja a leszállítást azzal, hogy túl sok mindent szeretne egyszerre.

 

Agilitás, mint emberi és csapattulajdonság

HR-esek kedvenc értelmezése. Az agilitást proaktív viselkedésként értelmezi, mind egyéni, mind csapat szinten.

Mikor használható: szervezeti kultúra függvénye. Egyes szervezeti kultúrák lehetetlenné teszik, más szervezeti kultúrák eleve úgy működnek, hogy csak a proaktív, agilis kollégák tudnak érvényesülni.

Nehézsége: (véleményem szerint) a proaktivitás nehezen fejleszthető, ha valaki nem az, nehezen tehető proaktívvá. Másik oldalról viszont a meglévő proaktivitás könnyen letörhető.

 

Agilitás, mint termékfejlesztési modell

Az agilis termékfejlesztés az egyik leggyakoribb értelmezési mód, talán az agilitás esszenciája. Azt jelenti, hogy egy minimálmegoldással kimegyek a piacra, információt gyűjtök, értékelem, és az alapján korrigálok. Ekkor beszélhetünk csak arról a gyakran említett feltételről, hogy nem tudjuk előre meghatározni a terjedelmet, hogy adott idő alatt, adott költségkeretből hová fogunk eljutni.  Agilis személetmódot feltételez, a klasszikus agilis technikák, módszertanok kiválóan támogatják.

Mikor használható: Akkor a leghatékonyabb, ha valami olyan, új termék vagy szolgáltatás piacra viteléről van szó. Az új részfunkciók között nincs, vagy korlátozottan van összefüggés (függetlenek a user storyk), ekkor lehet a prioritásokat könnyen változtatni a funkcionalitás tekintetében

Nehézsége: meglévő termék kiváltására korlátozottan alkalmas, vagy csak nagy kompromisszumokkal.

 

Agilitás, mint validációs és kockázatcsökkentő technika

Ha a funkciók között jelentős összefüggés van, vagy bonyolult folyamatok vannak a háttérben, esetleg jogszabályok, vagy eltérő érdekű stakeholderek korlátozzák a megoldási lehetőségeket, a folyamatos változtatás lehetősége elvész. Ilyenkor nem tudjuk megúszni a megoldás üzleti tervezését, a követelmények elemzését, az ellentmondások felismerését és feloldását. Azonban így is érdemes kisebb részekre bontani a projekteket, az üzleti értékesség vagy a kockázat mérlegelése alapján.  A kisebb részek implementációjának tapasztalatait a következő fázisban figyelembe lehet venni.

Mikor használható: bármikor, módszertantól függetlenül. A darabolás történhet funkcionalitás vagy folyamatok mentén, földrajzilag, ügyfélszegmensenként, stb.

Nehézsége: sokan csak a fejlesztést darabolják, a scope-ot nem, ezáltal erősen növelik a kockázatot, illetve a teljes működés szintén csak a végső hajrában ellenőrizhető.

Agilitás, mint szervezeti modell

Az agilis szervezeti modellben a szervezet is átalakul az agilis elveknek megfelelően (lsd. Spotify modell). Az agilis szervezeti kultúrát gyakran mossák össze az agilis szervezeti modellel, pedig az előbbi létezhet az utóbbi nélkül, fordítva viszont nem igaz.

Mikor használható: csak és kizárólag akkor, ha az agilis gondolkodásmód már beépült a szervezeti kultúrába. Ennek utolsó lépcsője lehet a szervezet átalakítása, ahol ez ésszerű.

Nehézsége: az agilis szervezeti felépítés nem vonja maga után a szervezeti kultúra megváltozását. Nagyon gyakran csak a pozíciók átnevezéséről van szó. Tanácsadók szerint a kiváltott káosz és a fluktuáció a transzformáció szükséges átmeneti velejárója. Hát majd meglátjuk.

 

Agilitás, mint Scrum

Módszertani keretrendszer, merev keretekkel, definiált szertartásokkal (Daily standup, sprintek, backlog, retrospektív, stb). A merev kereteken belül nagy rugalmasságot biztosít. Nagy előnye, hogy a projektvezetéshez szükséges soft elemeket (kommunikáció, felhatalmazás, önszerveződés, stb.)  a módszertan szerves elemeként definiálja. Zseniális, de sokszor kifelejtett eleme a retrospektív, ami már menet közben korrekciókat tud tenni a jó csapatműködés, vagy a jó termék irányába. Sokaknak csak ennyi az agilitás.

Mikor használható: bármikor, bárhol, akár agilis szemléletmódtól függetlenül is (ilyenkor azonban a követelményeket hagyományos módon kell definiálni, inkább hibrid megoldás).

Nehézsége: ha nincs mögötte tartalom, vagy rosszul definiált a projekt, vagy az alapvető feltételeket nem sikerül biztosítani, pont ugyanolyan rosszul működik, mint a vízesés modell.