Ismerősen hangzik? Ami igaz volt a kilencvenes években, hatványozottan igaz manapság. A folyamatosan változó környezet, végtelen információáramlás és sokszínű lehetőségek valós vagy képzelt versenyhelyzetet teremtenek és feszültséget tartanak fent, a volatilitás tehát könnyen fordulhat át káoszba.

Photo by Vladimir Kudinov from Pexels

Tudatosság és fókusz, mint a volatilitás szárnysegédjei

Ha nincsen meg a kristálytiszta fókusz, pillanatok alatt elveszíthetjük a fonalat, amivel nem csak a hatékonyság csökken, de ez stresszt is szül, ami idővel rátelepszik a munkakörnyezetre és érezhetően csökkenti az életminőséget.

Tudományos kutatások nélkül is mindenki érzi, hogy a végzett tevékenység folyamatos megszakítása nem tesz jót. Biztos voltam benne, hogy többször hallottam korábban azt, hogy minden megszakítás után 25 percbe telik újra teljes figyelemmel visszatérni egy adott feladathoz, úgyhogy gondoltam, megosztom itt a pontos számot elrettentő példaként. Érdekes módon egy gyors angol nyelvű Google keresés valóban kidob első helyen egy cikket, amelyben a kerekített 25 perc szerepel, de az abban hivatkozott tanulmányban sehol nem jelenik meg ez az adat…

Ez egyrészt jól mutatja, hogy érdemes az online talált cikkekbe az első mondatnál mélyebben is beleásni, ha valós adatokat keresünk. Másrészt viszont a számszerűsített értéknél érdekesebb eredményre jutottak az amerikai University of California és a német Humboldt Universität kutatói: a folyamatosan megszakított környezetben dolgozó tesztalanyok gyorsabban végeztek adott feladatokkal, mint akit nem zavartak meg.

Arra a következtetésre jutottak, hogy aki tudja, hogy folyamatosan meg fogják szakítani, fokozatosan átáll egy hektikusabb munkamenetre, hogy proaktívan bepótolja az időt, amiről tudja, hogy ki fog esni. Ennek következtében a megszakítások magasabb stresszhez és frusztrációhoz, időnyomáshoz vezettek. A végeredmény minőségéről nem is beszélve.

Akit mégis érdekel a pontos kiesett idő:

• a Microsoft tanulmánya szerint 15 perc, beleértve a kizökkenést követő pótcselekvéseket.

Mégis, miért nem teszünk akkor a folyamatos “pörgés” ellen? 

Silvia Bellezza (Harvard) és Neeru Paharia (Georgetown) egy érdekes kísérletben létrehoztak kitalált Facebook profilokat és arra jutottak, hogy ha folyamatosan elfoglaltságról és hosszú munkaórákról postolnak, akkor a tesztalanyok sikeresebbnek fogják gondolni a kitalált karaktereket, mint amikor szabadságról és nyaralásokról írnak.

Az elfoglaltság státuszszimbólum lett – aki nem pörög, nem sikeres. 

Adott tehát az elfoglaltság, így érdemes arra összpontosítani, hogy növeljük a hatékonyságot és csökkentsük a stresszt. A nehezen kiszámítható, változékony környezetben is tehetünk a folyamatos megszakítások kockázata ellen – mégpedig úgy, hogy rövidebb egységekre daraboljuk a feladatot. Minél rövidebb egy feladat, annál kevesebbszer lehet megszakítani.

A volatilitás rendszerszintű kezelése

A különböző agilis módszertanok egyik alapvetése éppen ez – iteratív megközelítés, amely kifejezetten a volatilitás rendszer szintű kezelésére kínál lehetőséget. A nagy, komplex feladatok részegységekre, rövid idő alatt leszállítható elemekre való lebontása segít folyamatosan eredményorientáltan dolgozni.

Mindez természetesen nem új. Jómagam először több mint 10 évvel ezelőtt, 2008-ban dolgoztam agilis projekten, és már akkor sem volt újdonság. A Kiáltvány az agilis szoftverfejlesztésért az évezred elején, 2001-ben fektette le a szoftverfejlesztés egy hatékonyabb módjának alapelveit.

Ezzel együtt nagyon érdekes volt, amikor a dublini székhelyű, online pénzügyi kereskedési platform fejlesztésével foglalkozó startupunkhoz csatlakozott a 90-es évek egyik legsikeresebb ír szoftvercégének, a NASDAQ-on jegyzett Iona Technologies-nak az egyik alapítója, Dr Sean Baker és fejlesztő csapata. A két hetes sprintek, jira-ban vezetett backlog és tesztelési sikerkritériumok meghatározása teljesen megváltoztatta a termékfejlesztést és sokkal közelebb hozta egymáshoz a fejlesztői és üzleti oldali csapatokat. Természetesen nem ment egyik napról a másikra, eleinte szokatlan volt, hogy a specifikációt nem tudjuk harmadszorra is változtatni, mert már leadtuk az igényt – sőt esetleg időközben el is készült – de viszonylag rövid időn belül átalakult a céges kultúra. Gyorsabbak, motiváltabbak, agilisak lettünk.

Mint a változásmenedzsmentnél általában, itt is igaz volt, hogy:

általában túlbecsüljük, hogy mire vagyunk képesek egyetlen nap alatt, de alábecsüljük, hogy mi lehetséges egy év leforgása alatt.

Természetesen változékony munkakörnyezettel és folyamatosan változó igényekkel nem csak szoftverfejlesztők találkoznak, hanem alapvetően bárki. Kivétel talán az a pár száz bennszülött, akiket megpróbálunk megóvni egy találkozástól és attól, hogy a VUCA világhoz hasonló szókreációkkal kelljen szembesülniük.

IT területen a nagy, komplex vállalatok legacy rendszerein dolgozó csapatok is fokozatosan próbálják beépíteni az agilis módszertanok nyújtotta előnyöket, változó sikerrel. Személyes tapasztalatom szerint a tudományosan felcímkézett bimodális IT vagy – felismerve, hogy azért két lehetséges haladási sebességnél több van – multi-speed IT jól hangzik, de többnyire csak azt rögzíti, hogy valóban, van, amit lehet gyorsan csinálni (pl. frontend) és van, amit nem (pl. legacy backend). Mindenesetre ígéretes, hogy a kettő összehangolásával, az optimalizálásért és stabilitásért felelős csapatok munkaszervezésének rugalmasabbá tételével egyre több helyen foglalkoznak. Akit érdekel, hogy milyen módszertanok segíthetnek megoldani ezt a kérdést, olvasson utána például a Safe Agile Framework-nek (SAFe).

Hasonlóan érdekes fejlemény, hogy az elmúlt évek során az IT területen túl is számos helyen kísérleteznek agilis módszertanok bevezetésével a gyorsan változó feladatok hatékony kezelésére. Legyen szó akár agilis alapelvek mentén kialakított vállalati működésről (a Spotify példájáról érdekesen ír egy majdnem-bennfentes) vagy hagyományos cégek agilis átalakulásáról (hazai példák között találjuk az OTP-t, NN-t és Magyar Telekomot), mindenhol megtalálható az a bevett módszer, hogy részegységekre bontják le a komplex feladatokat, amelyek így belátható időn belül megvalósíthatóvá válnak.

A volatilitás fegyelmezése kanban boardok használatával

Ahol értelmezhető a sprintekben való szállítás, ott a szoftverfejlesztésből átvett, viszonylag pontosan meghatározott szerepeket és működési modellt hozó scrum lehet releváns, de ahol nem, egy kanban board-on pontosan vezetett feladatlista ott is hasznos. A trükk az, hogy a párhuzamosan végzett feladatok számát maximalizáljuk, így biztosítva, hogy több minden készül el – ha nem fogynak el a work in progress elemek, nem kezdhetünk újat.

Érdemes kipróbálni. Ha másra nem, arra mindenképpen megtanítja a csapattagokat, hogy pontosabban becsüljenek erőforrást részfeladatokra, amivel rengeteg üresjárat megspórolható. Ráadásul több a mikro-sikerélmény, illetve rugalmasan módosíthatók a soron következő feladatok.

Segít elmélyíteni a stresszmegelőzés szempontjából is igen hasznos szemléletmódot, miszerint:

Done is better than perfect. (Except when it needs to be perfect).

A második részre mindig ott van az iterálás…

A kezdéshez nem kell sok, egy kanban board például számos felhő alapú szolgáltatásban rövid időn belül összerakható. Én a paymo-t használom, de alapvetően mindegyik ugyanazt tudja.

Íme egy élő példa:

Fontos, hogy nem szabad megijedni a divatos, sokszor evangélium szintjén használt fogalmaktól. A dogmák a történelemben sehol nem jelentettek biztos utat a sikerhez, és ez itt sincsen másképp. Amikor egy tíz éve külföldi startupokban dolgozó fejlesztő barátomat megkérdeztük, hogy minden sprint végén tartsunk-e retrospektívát egy saját fejlesztésnél, annyit mondott, hogy:

„Ha mindenképpen ceremóniákat akarunk, hoz papi ruhát, de ha nem, inkább nézzük meg, hogy milyen rendszerességgel van értelme. Ha nagyon rövidek lesznek a sprintek, csak kapacitást égetünk.”

Ambiciózus, de reális célok

Alkalmazási területtől függetlenül – az alapvetéseket figyelembe véve – akkor tud értéket teremteni az agilitás, ha a mindennapokban is működőképes az adott szervezetben. Egy rugalmas szervezet kialakítása minden esetben kemény munka, és ha lustaságból hagynánk ki módszertani elemeket, ne tegyük, de fontos felismerni, hogy mi reális egy adott vállalati kultúrában, és mi nem. Az ambiciózus célok segítenek fejlődni, de az irreális elvárásoktól óvakodjunk. A vezetők egója nem lesz kisebb, a projektmenedzserek nem fogják egyik napról a másikra megtalálni a helyüket egy agilis szervezetben és a termékmenedzser sem lesz varázsütésre PO. Ha ezeket sikerül okosan kezelnünk, az nem felesleges politizálás, hanem pragmatikus változásmenedzsment.

A volatiltitást fegyelmező alapismeretek gyorsan elsajáthatítóak például egy Certified Scrum Master képzésen, rengeteg online (oktató)anyag érhető el és természetesen külső segítségben sincsen hiány, de azért ez nem egy Chartered Financial Analyst képzés. Aki nem hajlandó néhány napot befektetni az alapok elsajátításába, az nem fog tudni mire építkezni, a csapból is folyó ezoterikus hókuszpókusznak fogja gondolni az agilis módszertant és közben a partvonalról figyeli, ahogy az egyre stresszesebb csapata fölött összecsapnak a VUCA világ hullámai.