Alulról jövő kis forradalom – így jellemzi az agilis szervezést oktatónk. A megközelítés igazából nem is új, mégis sokan mai napig ódzkodnak tőle, hiszen pontos használati útmutató helyett egy nagyobb szabadságot adó keretrendszert kapnak. Pedig sokan úgy is alkalmaznak ilyen jellegű megoldásokat, hogy nem is tudnak róla.
Csépányi Tamás, a magyar Deutsche Telekom IT Solutions Scrum Mastere ebben a minőségében hat éve dolgozik, míg projektvezetőként már bő egy évtizede. Emellett a Laba keretein belül is több kurzust tart. Mesterdiplomáját tíz éve a Corvinuson szerezte, azóta az említett cég elődje, a T-Systems mellett volt projektvezető a Libri-Bookline-nál és az ITBN Conf-Expónál is.
Sokan igyekeznek részekre bontani a feladataikat, rugalmasnak lenni és az ügyfeleket jól kiszolgálni. Hol kezdődik az igazi agilitás?
Ez értelmezés kérdése. Szerintem ahol már akár egyetlen interációt is bevezetnek, vagyis nem egyben végeznek el egy feladatot, hanem újratervezik azt, ott már elindultak az agilitás irányába. Mindenhol, ahol nem egy nagyon egyszerű, egyenes folyamatról van szó, mint amikor például kiveszem a szemeteszsákot és leviszem a nagy kukába, ott már fellelhető az agilitás valamilyen formában.
Heti és havi tervezésben is sokan gondolkodnak. Egy iteráció vagy sprint miben más ettől?
Ha egy projektnél heti szinten zajlik a tervezés, az már egyfajta agilitás. Az már ebbe az irányba mutat, ha rájövünk, hogy nem arra van szükségünk, hogy a projekt elején egyszer tervezzünk meg mindent és esetleg később korrigálgassuk azt, hanem folyamatosan kell tervezni, mert nincs minden információ a birtokukban. Innen egy lépéssel tovább megyünk az iterációkban vagy sprintekben való gondolkodással, a kettő egyébként ugyanazt jelenti, ez utóbbi a Scrumban használt fogalom. A Scrum keretrendszer egy olyan pluszt is ad a tervezéshez, hogy van egy úgynevezett backlog, a tennivalók listája, ami mindent tartalmaz, ami a termék elkészítéséhez szükséges, mégpedig priorizálva. Ez már egy fontos különbség a sima heti tervezéshez képest. A backlogban megjelennek az ügyfelek igényei is, például hogy egy szoftver egyik gombját helyezzék át a jobb felsőből a bal alsó sarokba. Ezt a fejlesztők és az üzleti elemzők lefordítják fejlesztési feladatokra és ez jelenik meg a teendők között, amikor aktuálissá válik. Ezeket sprintenként szűkebb részhalmazokra bontjuk, ezekből lesznek az úgynevezett Sprint Backlogok.
Lehetnek akkor olyanok is, akik élnek ehhez hasonló módszerekkel és lényegében agilisen működnek, bár nem tudnak erről?
Igen, abszolút. Szokták is mondani, hogy az agilitás, mint fogalom, nem más, mint a józan ész újracsomagolása egy modern brandben.
Ez a logikája az emberi természetnek, csak erről nem tudunk. De ha erre rájöttünk, akkor már mögé lehet tenni gyakorlatokat és módszereket, melyekkel ez kicsit szabályozottabban, hatékonyabban működhet. Mint ahogy bárki puszta lelkesedésből szervez egy vacsorát vagy csapatépítőt, az sem tudja feltétlenül, hogy miközben szervezte, tulajdonképpen „projektet menedzselt”. De attól még azt csinálta.
Ha megvan ez a felismerés, az ilyen módszerek mit tudnak a munkához hozzátenni?
Onnan érdemes elindulni, hogy az érintettek tudnak-e olyan közös feladatlistát létrehozni, amit mindenki ért, mindenki tud használni. Praktikusan ez a lista az origója az egésznek. Aki olyanon dolgozik, amit nem lát a listában, az tulajdonképpen felesleget termelt. Ugyanakkor nem minden szektorban és munkakörben lehet ilyet írni, hiszen valahol a feladatok kiszámíthatatlanok. Sosem tudod, hogy kinek romlik el a nyomtatója és hogy éppen hány ügyfélszolgálati panasz lesz. Ezekben az esetekben, üzemeltetési típusú feladatoknál inkább a flow-ra helyezném a hangsúlyt. Egy egyszerű példán szemléltetve: egy ruhamosás is lehet flow. A koszos ruhák szennyeskosárba helyezésétől különböző munkafolyamatokon át addig tart, ameddig összehajtva a szekrényben tisztán meg nem találhatók a ruhák. Ezt a folyamatot pedig már lehet mérni, hiszen látjuk, mikor került bele a ruha, és mikor raktuk vissza a szekrénybe. Így már optimalizálni is lehet, megnézve, hogy melyik lépés, azaz melyik részfolyamat meddig tart. Végig egy folyamatban érdemes gondolkodni, ahol lépések sorozatával teremtünk végül valamilyen értéket. Ha a projektvezetők erre nyitottak, mindent lehet így mérni: a lépéseket, hogy ki mennyi időt tölt el ugyanolyan feladattal. Ezzel már tettünk egy lépést egy Kanban típusú agilis működés felé.
Egy micsoda felé?
Ez a Toyota Production Systemből ered, japánból és egy, nagyon egyszerű módszerről beszélünk. Bármilyen folyamat lépéseit, szakaszait felrajzolhatjuk oszlopokként egy táblára. A mosásnál maradva az első lépés a szennyes összegyűjtése, utána a színek szerinti válogatás, majd a mosógépbe pakolás és így tovább. Ha erre a táblára ruhadarabokként felteszel egy-egy cetlit, akkor láthatóvá válik, hogy melyik darab pontosan hol tart a mosás teljes folyamatában. Egyszersmind mérhetővé is teszed az előrehaladást. Ezzel mindenki látja, hogy éppen ki hol tart a saját feladatában, s akár láthatja mondjuk egy csapatvezető is. Ha valaki hosszan időzik egy feladaton, akkor meg lehet kérdezni, mi a gond, hol az elakadás. Egyszerre hozunk így létre átláthatóságot és mérhetőséget, ezzel megteremtve a lehetőségét a folyamat optimalizálásához.
Az IT-szektorban gyökerező agilitás rugalmasságának az egyik megvalósulása, hogy építenek a korán kiadott béta verziókhoz érkező visszajelzésekre. De nem árthat egy cég reputációnak a kiadott, kvázi félkész program?
De, ha nem jó minőségű terméket tesznek ki vagy pedig túl korán teszik ezt, az természetesen árthat, de ennek kivédésére vannak vannak különböző gyakorlatok. Vannak gyártók, akik nem túl etikus módon – a felhasználók számára érzékelhetően, de nem bevallottan – teszik a szoftver korai verzióját élesen elérhetővé, majd a felhasználói visszajelzések alapján kijavítják a hibákat. Így mondjuk pénzt és időt tudnak megspórolni az átfogó teszteléseken. Az etikus megoldás viszont inkább úgy néz ki, hogy vannak korai tesztelésre jelentkező felhasználók, akiktől az az elvárás, hogy miután megkaptak egy még nem teljesen jó programot és használni kezdik, folyamatosan részletes visszajelzéseket adjanak a gyártó felé. Például funkcionális hibáról, amikor nem működik valami, vagy nem funkcionálisról, amikor például egy funkció lassú. Ehhez kapcsolódik a minimum viable product (MVP), azaz a minimálisan életképes termék agilis logikai eleme. Vagyis hogy ne fordítsunk több energiát a termék fejlesztésére, mint ami feltétlenül szükséges ahhoz, hogy értéket teremtsen és használható, illetve eladható legyen. Ugyanis nem a „tökéletes”, hanem a „kész” megoldás a jó. A kész terméket már kisebb-nagyobb kompromisszumokkal tudják használni a felhasználók, elkezdhetünk tapasztalatokat gyűjteni. Innen pedig iteratív módon, folyamatosan fejlesztve tudjuk mindig kicsit jobbá és jobbá tenni azt.
A Scrum csak az egyik keretrendszer, amiben agilisan dolgozhatunk?
Igen, van több is. Ott van például az XP, az „extrém programozás”, az is egy keretrendszer, tehát gyakorlatok összessége. Ezeket nagy szabadságfokot adó, kvázi guide jellegű leírásként kell elképzelni, nem módszertanként. Mert egy módszertan az egy recept, amit pontosan kell követni, de ezek nem ilyenek.
Ha a Scrum sem recept, akkor micsoda?
A nagymama fejből lediktált, nem grammra pontos elkészítési módja, amiben olyanok szerepelnek, hogy „vegyél egy marék krumplit és vágd fel közepes darabokra”. Ezeket ködösebbnek is mondhatjuk, de inkább úgy érdemes ezekről gondolkodni, hogy ezek nagyobb szabadságot adó megfogalmazások. Ugyanis a gyakorlatban rá van bízva a Scrum Masterre, a csapatra és a környezetre, hogy az elkészítési módból mit és hogyan alkalmaznak.
Egy agilis módszereket használó projektmenedzser és egy Scrum Master között mi a különbség?
Leginkább az, hogy más a kettejük felelősségi köre. A projektvezetőé általában a teljes projektre kiterjed. Legtöbb esetben a övé a budget control, a határidők ellenőrzése, a kockázatkezelés és a kommunikáció felelőssége is. A projekt végrehajtása során pedig „ízlés szerint” be tud emelni agilis gyakorlatokat. Például tarthat standupokat, vagy bizonyos folyamatokat transzparenssé, mérhetővé tehet a Kanban táblával. Ezzel szemben egy Scrum Master egy adott terméken dolgozó csapat Scrum szerinti működéséért, pszichológiai értelemben vett biztonságáért és a kiszámítható haladásáért, fejlődésért felel. Ha létre kell hozni egy új szolgáltatást, amihez 3-4 különböző kompetencia szükséges, az ezen dolgozókat pedig úgy látja a projektvezető, hogy egy agilis keretrendszerben lehetnek a leghatékonyabbak, ezt fogja segíteni a Scrum Master. Azért fog felelni, hogy a projekten belül az adott termékért felelős csapat a megfelelő keretekben dolgozzon, kiszámíthatóan és egyre jobbá váljon eközben.
A hibrid projektvezetés mit jelent és kiknek érdemes kipróbálnia?
Úgy kell elképzelni, mint egy hibrid autót. Itt a két véglet a tervalapú, úgynevezett prediktív projektvezetés és az agilis megközelítés. A kettő között pedig tulajdonképpen minden hibrid. Az egyik véglet, a prediktív a minél pontosabban előre megtervezett feladatok mentén történő előrehaladást jelenti, amiben egy előre nem látott eseményt „változásként” értelmezünk, aminek a kezelésére külön folyamatot kell felállítani. A másik végletben, az agilitás esetén pedig mindent iterációkban, az értéket szem előtt tartva hajtunk végre, rövidebb időszakokban tervezve. Az már hibridnek mondható, amikor megjelennek az iterációk a megvalósításban, vagy több részletben adják át a terméket, több fázisban fejlesztik, vagy akár csak a fejlesztés során sprintekben gondolkodnak.
Azt azonban fontos megérteni, hogy mindent nem lehet és nem is kell agilisen csinálni, ezért van szükség a hibrid megközelítésre.
A projektek általában prediktív módon indulnak és egy bizonyos ponton, mondjuk a tervezés végével, ha már elfogadta az ügyfél a terveket, a fejlesztést lehet agilis gyakorlatok mentén végezni, például Scrum keretrendszerben. Majd a tesztelést vagy az átadást ismét lehetséges prediktív, tervalapú módon végezni. Ez teljesen normális a legtöbb projekt esetében manapság, ahol mutatkozik erre nyitottság.
Mennyire értik félre ezeket az egyre népszerűbb kereteket, alkalmazzák divatból rosszul őket?
Nagyon jellemző, hiszen sokszor ezek olyanoknak is újdonságot jelentenek, akik már évek óta ebben a szakmában dolgoznak. 20-30 éve dolgozó projektvezetőkön érzékelem azt, hogy még mindig tartanak az agilitástól és mintha egyfajta úri huncutságnak tartanák azt. Nyitottság híján pedig nem is tudják azt mélyebben megismerni. Emellett mindez szocializáció kérdése is, két-három évtizede a projektvezetőket úgy tanították, hogy amire van terved, az meg lesz valósítva, amire nincs, az nem. Ha nem tudod előre megtervezni az egészet, akkor megvalósítani sem fogod tudni. Én is ismerek ilyen attitűdben íródott könyveket, van is polcomon. Sőt, mivel az agilitásban nagy szabadságfokot hagynak az azt végrehajtóknak, a Scrum Guide például 14 oldal összesen. Nem pedig 6-700 mint a nehézsúlyú projektmódszertanok szoktak lenni. Így talán sokan beleesnek abba a hibába, hogy a keretrendszer rövidsége miatt komolytalannak, egyszerűnek tartják azt. Ezzel elsikkadnak a lényeg felett, amit a megvalósítás során észlelnének. De ha valamit egy 14 oldalas leírás alapján meg lehet csinálni, nagyobb az esélye, hogy egyszeri átolvasás után azt gondoljuk, mindent tudunk róla. Magasabb szintű menedzsmentnél is gyakran megesik, hogy ezt elolvasva úgy érzik: ismerik és másnaptól alkalmazni is tudják. Az ilyen úgynevezett „ismeretekből” adódnak aztán az olyan klasszikus tévhitek, mint hogy agilis projektben nem kell dokumentálni vagy hogy agilis projektek esetében természetes a káosz.
Viszont így nem lehet egyszerű belefogni, ha nincs egyértelmű használati útmutató.
Persze. Az egésznek egyszerre a csodája és a rákfenéje is, hogy egyrészt nincs pontos útmutató, az egyénekre van bízva a megvalósítása, másrészt itt emberekben kell bízni, hisz rájuk épül az egész.
Olyan, mint egy kis, alulról jövő „forradalom”. Ha nincs egy kompetens személy, aki az élére áll, világít az alagút végén, akkor nehezen lesz belőle valami. Elsőre ezért az olyan kompetenciát kell hozzá kiépíteni a cégen belül, mint a Scrum Master, az Agile Master és az Agile Coach. Ha valaki nyitott erre és elkezd utánaolvasni az interneten, vagy elvégez egy olyan képzést, amilyet a Laba tart, utána már elkezdheti bevinni ezeket a gyakorlatokat a saját projektjeibe. A backlogot, a napi státuszt, a sprinteket és a keretrendszerben szereplő többi megoldást. Hogy ilyen módon egyfajta úttörőként behozzák ezeket egy cég vagy projekt működésébe, ahhoz kell bátorság és a hibázásra való hajlandóság. Sok toxikus munkahelyen ugyanis a hibát például büntetik, miközben az agilitásban ez egy lehetőség a tanulásra.
Kapcsolódó kurzusok:
Való-e mindenkinek az agilitás, érdemes-e például a kkv-knek is megpróbálnia?
Nem való mindenkinek. Bizonyos területeket, mint például a harcászatban vagy akár az orvosi működésben muszáj hierarchikusan, parancselvűen szervezni, mert ezen emberéletek múlhatnak. De a bürokratikus működés és autoritáson alapuló munkaszervezés miatt az államigazgatásban sem túl gyakori vagy életképes az agilitás. Ugyanakkor a kkv-k vagy a manapság gyakoribb startupok és spin-offok könnyen tudják alkalmazni, persze területtől és iparágtól függően. A nagyvállalatoknál pedig kisebb egységeknél, projekteknél, illetve csapatonként és divíziónként lehet ezzel elindulni.
Magyarországon mennyire terjedt el, a cégvezetők mennyire fogadják el ezt a szemléletet?
A pénzügyi szektorban nagyon elterjedt már hazánkban is, számos banknál alkalmazzák. Náluk is leginkább az IT-részlegek, de például a termékfejlesztéseknél sok helyen jellemző. Ugyanis rádöbbentek, hogy a pénzügyi környezet sokat változik, amire gyorsan kell reagálni. Márpedig minél előbb kifejlesztenek egy új terméket, annál több ügyfelük lehet potenciálisan. Ha pedig a jogi környezet változik és ezt gyorsan le tudják követni, az is versenyelőnyt jelenthet a lassabban reagáló konkurensekkel szemben. Mindig az IT-vel kezdődik, de például az autóiparban is tudok olyan szereplőről, ahol a termékfejlesztést is már évek óta agilis szemlélettel végzik, mert fel kell venniük nekik is a lépést az erős versenytársakkal, illetve innovatívnak kell lenniük a fennmaradáshoz. Aminek jól meg tud ágyazni az agilis működés.
