Arról, hogy milyen is az agilis csapat, egy történet jut eszembe.
Egy barátom kis híján nem jutott be a filozófia szakra. Megnyerte ugyan az OKTV-t filozófiából, és ezt az eredményt az akkori rendszer egy maximális pontszámú emelt szintű érettségivel tekintette egyenértékűnek. Viszont a filozófia szakra magyarból és történelemből kellett felvételizni, és így néhány ponttal lemaradt. Végül talált valakit a tanulmányi osztályon, aki hajlandó volt őt meghallgatni és segített neki egy méltányossági kérvényt megfogalmazni.
A tanulmányi osztály a legtöbb egyetemen maga a rugalmatlanság. Szerintem az ilyen rugalmatlan szervezetek azért tudnak megfelelni a küldetésüknek, mert bizonyos elemeik a merev szabályok ellenére rugalmasak. A barátomat kisegítő tanulmányi előadónak nem kellett volna foglalkoznia egy még fel sem vett diák panaszával. Ez a fajta szervezeti merevség, ami egy egyetemen működött, vagy talán a mai napig is működik, az üzleti világban ma már teljesen elképzelhetetlen. Minden nagy cég kénytelen egyre rugalmasabban működni.
Ennek a követelménynek megfelelni nagyon nehéz, különösen egy régóta működő nagy szervezetben. Mára viszont olyan sebességgel változik az üzleti környezet, hogy a nagy cégek is kénytelenek a lehető leghamarabb reagálni. A szoftveripar volt az első olyan szektor, ahol a rugalmasság követelményét gyakorlatban és széles körben megvalósították, és innen származik az ilyesfajta munkaszervezés manapság használt megnevezése is, az agilitás.
Az agilis csapat alapja az Agilis szemlélet
Az agilitás azt jelenti, hogy egy szervezet képes a változásokra gyorsan, rugalmasan és fókuszáltan reagálni. Ha a rugalmas alkalmazkodás ma már nem választás kérdése, akkor az sem kérdés, hogy az agilis működést választjuk-e. Sokkal inkább arról kell beszélnünk, hogy a szoftverfejlesztésben jól bejáratott agilis működési módokból mit és hogyan tudunk hasznosítani, függetlenül attól, hogy a szoftveriparban vagy teljesen más területen tevékenykedünk.
Az agilitás egyfajta ideális állapot, amit sosem lehet teljesen elérni, de mindig lehet közelítő lépéseket tenni felé.
Ebben a cikkben megnézzük, hogy mik az agilitás legfontosabb elemei és mik lehetnek azok a bizonyos közelítő lépések. Véleményem szerint az agilitáshoz az agilis csapatokon keresztül vezet az út, ezért azt mutatom be, hogy milyen csapattal lehet ezeket a lépéseket megtenni. A példákat és magyarázatokat sokszor a scrum keretrendszerből fogom venni, mert ez a legismertebb implementáció, bár a legtöbb nagy cégben már nem az eredeti formájában létezik, hanem fokozatosan, apró lépésekben mindenütt a helyi követelményekhez alakították — éppen úgy, mint ahogy ezt egy agilis szervezettől elvárhatjuk.
Azt állítottam, hogy az agilitás — többek között — gyors reagálást jelent. A gyorsasághoz az kell, hogy a szervezetben közel legyenek egymáshoz a környezet változását érzékelő emberek, a döntéshozók és a döntések végrehajtói. A közelség ebben az esetben gyakori kommunikációt és gyors visszacsatolást, míg a távolság általában sok hierarchikus szintet, bonyolult függelmi és illetékességi rendszereket jelent.
az agilis csapatok Döntéshozatala
Egy szervezet működése annál rugalmasabb, minél közelebb vannak a döntések az ügyfelekhez. Egy fodrászüzlet az egyik legrugalmasabb üzletmenetet: a szolgáltatással kapcsolatos döntések nagy részét az ügyféllel közösen dolgozza ki a szolgáltató, aki sok esetben az üzletvezető, sőt akár a tulajdonos is egy személyben. Ez a modell attól működik, hogy a projektek nagyon rövidek, és egy projektnek csak egy ügyfele van. Emiatt aztán skálázni sincs értelme, mert nincs méretgazdaságosság. Nem véletlen, hogy nincsenek óriási, több száz székes fodrászatok, és a világ ismert márkái közül egyik sem fodrászat. Minél többen dolgoznak a projekten és minél több az érintett ügyfél, jellemzően annál messzebb kerül a döntéshozatal az ügyfelektől. Egy kis étteremben az ügyvezető még találkozhat az ügyfelekkel, de pl. egy gyorsétteremlánc esetében ez már teljesen lehetetlen.
Az a bizonyos gyorsan változó üzleti környezet, amihez dinamikusan alkalmazkodnia kell a szervezetnek, akár nagyon összetett is lehet. Ma már a makrogazdasági és a jogi keretek is borzasztó gyorsan változnak, de most egyelőre fókuszáljunk az ügyfelek igényeire, mert az agilis módszertanok kialakulásakor a szoftveriparban ez jelentette a legnagyobb kihívást. Hogyan tudunk olyan csapatot létrehozni, amelyik gyorsan, rugalmasan tud reagálni a változó ügyféligényekre?
Az agilis csapat kicsi és autonóm. A kis méret azért fontos, mert így mindenki ismer mindenkit, hamar kialakulnak a csoportnormák, gyors és pontos a kommunikáció és a döntéshozatal is gördülékeny. Az autonómiának köszönhetően a döntéseket ugyanazok hozzák meg, mint akik később végrehajtják azokat, így a kommunikációs csapdák elkerülhetők. Az agilis csapat így felelősséget is vállal, hiszen ők viselik a döntések következményeit, valamint erősebb az elköteleződés is, mivel a legtöbben a saját döntéseikhez könnyebben tartják magukat. Fontos, hogy autonómiája a csapatnak van, tehát csapat együttesen vállal felelősséget az elvégzendő munkáért, és a csapattagok egyénenként csak egymásnak tartoznak felelősséggel. És hogy mire terjed ki az autonómia? Arra, hogy hogyan végzik el a kijelölt munkát. Munkaszervezés, időkeretek, sőt egyes helyeken akár a prémium elosztása is lehet a csapat döntése. Az ügyfél csak abba szól bele, hogy min dolgoznak, függetlenül attól, hogy tényleges külső ügyfélről, vagy a szervezeten belüli ügyfélről beszélünk, legyen az termékfejlesztő, a marketingcsapat vagy akár az ügyvezető.
Ez azt is jelenti, hogy a vezetők egy csomó hagyományos vezetői feladatot lepasszolhatnak. Igazából le sem kell passzolni, mert fel sem merül, hogy a csapaton kívül bárki beleszóljon abba, hogy ki melyik feladatot vállalja, vagy hogy az egyik csapattag személyes problémák miatt épp kevesebbet tud teljesíteni.
A product owner szerepe az agilis csapatban
Említettem, hogy annál rugalmasabb egy szervezet, minél közelebb vannak a döntéshozók az ügyfelekhez. A scrum keretrendszerben számomra ez az egyik legérdekesebb „hack”: a csapat jellemzően nem találkozik a tényleges ügyféllel, de rendelkezésére áll a product owner, aki az ügyfelet képviseli. Neki lehet feltenni a kérdéseket, ő tartja a kapcsolatot a tényleges ügyféllel, legyen az külső vagy belső ügyfél. Ő priorizálja a feladatokat az ügyfél érdekeit érvényesítve. Egyébként Igazi kommunikációs interface: tolmácsol az ügyfél és a fejlesztők között. Ez gyakran igazi tolmácsolás, a fejlesztők nem ugyanazt a nyelvet beszélik, mint az ügyfelek. Máskor inkább csak szűrőként funkcionál, áramvonalasítja a kommunikációt a csapat és az ügyfél között.
Egy ilyen önszerveződő, agilis csapat akkor tud jól működni, hogyha az együttműködésnek jól szabályozott keretei vannak. A kis csapat kommunikációs előnyei akkor tudnak érvényesülni, ha van idő és tér arra, hogy az emberek beszéljenek egymással. A scrum keretrendszerben használatos ceremóniák például ilyenek. Aki hallott már a scrumról, az biztosan hallott a standup-ról is. Ez tulajdonképp egy megbeszélés fura szabályokkal: a munkanap elején mindenki nagyon tömören beszámol az előző napi haladásáról, az aznapi terveiről és az esetleges akadályokról. Azért standup, mert mindenki áll, így senki nem kényelmesedik bele a beszélgetésbe, így gondoskodnak arról, hogy ne tartson túl sokáig. A szabályok szigorúak, de cserébe mindenki érti, hogy miért van rájuk szükség. A keretek fenntartására a scrumban külön személy van, a scrum master. Ő gondoskodik arról is, hogy a megbeszélések az előre meghatározott mederben folyjanak, és ha valakinek valami olyan közlendője van a csapattal, ami kilógna a megbeszélés keretéből, arra szervezzen egy másik megbeszélést, ahol ezt megoszthatja. Védi is a csapatot, gondoskodik arról, hogy a product owneren kívül más ne kérjen túl nagy szívességeket.
Nem esett még szó a csapattagokról: az agilis csapat generalistákból áll, akik tudják egymást helyettesíteni. Lehetnek specialisták bizonyos területeken, de az agilis csapat kialakításában fontos szempont, hogy egy speciális szakértelem lehetőleg ne alakítson ki szűk keresztmetszeteket, nagy átfedések legyenek a kompetenciákban.
Hogyan működik az agilis csapat?
Az autonóm csapat sem csodaszer, de nagyon sok vezetői munkát kommunikációt meg lehet vele spórolni. Az önrendelkező csapat akkor lehet hatékony döntéshozó, ha világosak és egyértelműek azok az értékek, amikhez mindenki tartja magát. Az agilitás maga is egy kiáltvánnyal kezdődött, és még ma is sokan egyfajta mozgalomként tekintenek rá.
Talán a legfontosabb ilyen érték a transzparencia. Már sok szó esett a kommunikáció fontosságáról, és azt beláthatjuk, hogy semmilyen kommunikáció nem lehet hatékony, ha valaki a megtévesztés szándékával vesz benne részt. A transzparencia egy kicsit többet jelent annál, hogy nem szabad hazudni. Inkább egy érték, törekvés, hogy a kommunikációnk minél kevésbé akadályozza az információ áramlását. Ha valaki elkésik, akkor nem keres utólag kifogásokat, de azt elmondja, ha a gyereke beteg, mert így lehet tudni, hogy nem a közös projekttel kapcsolatos aggodalom ült ki az arcára. Ha valaki hibázik, akkor nem próbálja eltitkolni, hanem minél előbb tudtára adja a csapatnak, mert a felelősség közös. Ha a transzparencia a csoportnorma része lesz, akkor számíthat rá, hogy a csapat többi tagja is így tesz hasonló helyzetben, és senkit nem ér bántódás, ha hibázik, hiszen mindenkivel előfordul ilyesmi.
A transzparens kommunikációhoz az is hozzátartozik, hogy mindenki tisztában van a projekt előrehaladásával, sőt ez gyakran nagyon látványos vizuális formában a közös térben jelenik meg (pl. Kanban tábla). A közös, rendszeres ceremóniák ahol szigorú, de nagyon egyszerű és világos keretek vannak, mind a transzparens kommunikációt szolgálják. A rendszerességnek különleges jelentősége van. Bizonyos megbeszéléseket akkor is meg kell tartani, ha éppen akkor senki nem érzi különösebb szükségét. A scrumban van egy „retrospektív„-nek nevezett megbeszélés, minden iteráció végén meg kell tartani és össze kell gyűjteni a tapasztalatokat. Néha nehéz elképzelni, hogy egy csapat tagjai több éves együttműködés után mit tudnak még mondani egymásnak. Mégis az a tapasztalat, hogy ezeken a megbeszéléseken fontos felismerések születnek, és megfogalmazódnak olyan lépések, amik a csapat működését javítják. Az agilis csapat ugyanis a saját fejlődéséért is felelősséget vállal, és kis lépésekben állandóan javítja a saját működését.
Miért legyen egy vezető agilis?
Az agilitás és a csapatok autonómiája nagyon hatékony munkát tesz lehetővé és komoly terheket vesz le a vezetők válláról. De talán ennél is fontosabb, hogy a legtöbb ember szívesebben dolgozik autonóm csapatban és ezért kisebb a fluktuáció. Ma a munkaerő legnagyobb része az Y generáció tagja, akik nagyon értékelik a csapatmunkát és a rugalmasságot. A „mai fiatalok”, vagyis a Z generáció ugyan individualistább, de kifejezetten elvárja, hogy értse és alakíthassa a csapata célját és működését.
Az agilitás nem mindenható, de elég jó választ ad egy csomó nagy kihívásra, ráadásul vannak iparágtól függetlenül alkalmazható aspektusai. Kíváncsian várom, hogy melyik lesz a következő olyan szektor, ahol olyan tömegesen fogják alkalmazni, mint a szoftveriparban.
Amennyiben szeretnél a saját szervezetedben is agilis csapatokat kialakítani (legyen az IT vagy nem IT szervezet), keress meg minket bátran!
