Agilis elismerés

Szerző: | 2018. 11. 16. | Agilis transzformáció az IT-ban

Egy hierarchikus szervezetben a beosztottak a főnök utasításait követik, és ő az, aki elismeri a munkájukat. Az önszerveződő csapatokban azonban nincs főnök. Akkor kitől várhatjuk az elismerést?

3-4 éven keresztül Svájcban egy nagyvállalatnál dolgoztam, ahol lehetőségem nyílt több agilis csapat tagjaként is megtapasztalni, milyen is egy innovációval foglalkozó szervezeti egységben dolgozni, miközben új termékeket/szolgáltatásokat vezetünk be a svájci piacra.

A legtöbb csapat élén nem volt kinevezett vezető fejlesztő, így a csapatnak közösen kellett szakmai kérdésekben konszenzusra jutnia. Korábban többször is dolgoztam vezető fejlesztőként és saját cégnél CTO-ként, és ilyen helyzetben mindannyiszor felelősséget vállaltam a termékek szállításáért és magas szakmai minőségéért. Ezért a csapaton belüli egyenrangúságot elsőre nagyon furcsálltam Svájcban. Mivel semmilyen kitüntetett szerepem nem volt a csapaton belül, úgy éreztem, hogy miközben az egyik sprint követi a másikat, nincs más dolgom, mint ledarálni a feladatokat. Egy adott terméken belül egyetlen terület sem volt kizárólagosan dedikálva senkihez, ehelyett az, aki éppen szabad volt, levette a következő feladatot a falról, és elkezdett dolgozni azon.

A csapat teljesítményét még csak-csak elismerték így vagy úgy, de csak ritkán éreztették velem azt, hogy megbecsült, esetleg pótolhatatlan tagja lennék a szervezetnek. Úgy éreztem, hogy amit csinálok, azt más is ugyanúgy meg tudná csinálni.

Saját ismerősi körömben is hallottam hasonló személyes történetet. Az egyik ismerősöm mesélte, hogy egy új céghez került UX designerként (Magyarországon), ami teljes mértékben önszerveződő alapon működött (kb. 20 fős cég), és kilépett 1-2 hónap után, mert úgy érezte, nem becsülik meg, csak egy dolgozó a sok közül. Inkább elment egy másik céghez dolgozni vezetőként.

Vezetővé válás egyéni felelősségvállalással

A svájci nagyvállalaton belüli startup szervezetben sok lehetőséget láttam a vezetőség és a munkatársak nyitottsága miatt, de a termék miatt is. Eszem ágában sem volt máshová menni, ezért úgy döntöttem, nincs más lehetőségem, találnom kell egy olyan kis területet a terméken belül, amely számomra fontos, és amivel még nem foglalkozik senki.

Abban az időben a termékfejlesztés abban a fázisban volt, amikor az első felhasználók már elkezdték használni a terméket. Azon túl, hogy tudtuk, sokan használják szívesen a rendszert, nem volt átfogó képünk arról, hogy a terméknek milyen esetleges defektjei vannak. Mivel a rendszer egy desktopalkalmazás volt, nem volt lehetőségünk meglévő szerveroldali logokból a megfelelő következtetéseket levonni, ezért ki kellett építenünk egy olyan rendszert, amely képes volt a kliensekről adatokat begyűjteni, és azokat transzparenssé tenni, vizualizálni (testing in production). A felvetésemet a csapaton belül mindenki egyetértéssel fogadta, és annak elvégzését tényleg szükségesnek tartotta, ezért elkezdtem ezen dolgozni, amihez a PO-tól is megkaptam a felhatalmazást.

De azért az út nem volt ennyire zökkenőmentes. Több munkatársamat és a menedzsmentet is meg kellett győznöm a változás előnyeiről. Nem mindenki támogatta azonnal ezt a változást, mivel az szembement a status quóval, de mivel a piacon gyorsan szerettünk volna bizonyítani, amihez szükség volt arra, hogy magas minőségben szállítsunk, végül is mindenki belement a változtatásokba. Tesztelési stratégiát váltottunk, és a release-ciklust rövidítettük le a töredékére. Ez a szervezetben dolgozó munkatársak korábbi munkarendjét felborította. Természetesen nem volt konfliktusmentes a váltás.

Az eredmények azonban magukért beszéltek:
  • Jelentősen, mérhető módon növelni tudtuk a termék minőségét, és sokkal gyorsabban szállítottunk, mint korábban.
  • Egy idő után a csapat számára fontossá vált ez a kis alrendszer, ezért később a többiek is továbbfejlesztették, és nagyban támaszkodtunk az éles üzemeltetésnél az általa megjelenített adatokra.

Az elismerés forrása

 Gyakran használják a cégek a SCRUM keretrendszert az agilis működés kialakításához. A termékfelelős (product owner, PO) felel a product backlog összeállításáért, amit később a csapat kisebb feladatokra bont, majd azokat leszállítja.

A csapat megosztott felelősséggel (shared responsibility) tartozik a sprintcél teljesüléséért. A sprint review-n a csapat közösen demózik, és mindenki bemutatja, milyen részeket fejlesztett.

Mivel a PO határozza meg a célokat, és az ő felelőssége a backlogelemek létrehozása, és neki is demózunk, ezért nagyon fontos, hogy a demó végén adjon valamiféle visszajelzést. A csapat így kaphat elsődlegesen elismerést az elvégzett munkáért. Azonban van egy kis bökkenő: A csapat kapja az elismerést, nem pedig személyesen az egyes fejlesztők, ez pedig hosszabb távon nem feltétlenül elegendő az egyes fejlesztők számára ahhoz, hogy úgy érezzék, az általuk egyedileg hozzáadott értéket megfelelően értékelik.

A csapat közösen vállal felelősséget a termék sikeréért, mivel közös a vízió, közös a termék, közös a kód (shared vision, shared responsibility, collective code ownership). Emellett viszont, tapasztalatom szerint, mindenki számára fontos, hogy legyen egy olyan részterület a nagy egészen belül, ami a szívügyévé válik, amiért felelősséget érezhet, és amin szívesen dolgozhat. Ezt érdemes a csapatban nyíltan megbeszélni: A csapattagok számoljanak be arról, kit mi érdekel, és ezeket később érdemes meg is jeleníteni valamilyen formában.

  • Valakit az érdekel, hogy a SonarQube-ban folyamatosan mérje és transzparenssé tegye a termék minőségét?
    Remek, csinálja meg, ebből a csapat csak profitálhat.
  • Valakinek az a fontos, hogy egy olyan naplózás kerüljön a rendszerben megvalósításra, ami üzembiztos, nem veszít üzeneteket, és mindig visszakereshető?
    Gyerünk, ez is jó mindenkinek.
  • Valakinek az a szívügye, hogy megmérje, hogy az alkalmazás egyes funkcióit hogyan és milyen gyakran használják a felhasználók?
    Ez igazán szuper, erre is szükség van.
  • Valakinek az a fontos, hogy transzparenssé tegye a rendszer API-ját?
    Találjon ki erre egy jó megoldást, és vezesse be.
  • Valakinek kifejezetten az egyik feature a szívügye?
    Biztos, hogy annak a folyamatos fejlesztéséből is lehet profitálni valahogyan.

A lehetőségek tárháza végtelen.

➔ Ha közösen meghatározzuk, hogy ki milyen „ügyet”, részterület sorsát viseli különösen a szívén, akkor annak akarva-akaratlanul a vezetőjévé válik, ő lesz az a hiteles személy, akit azon ügy kapcsán majd felkeresnek.
Hiszen ha valóban érdekli az a terület, biztosan utánanéz, hogy mások hogyan oldanak meg az azzal kapcsolatban felmerülő egyes problémákat, folyamatosan fejleszti magát, vagyis idővel az adott terület szakértőjévé válik. Hiszem, hogy ha valami igazán fontos a számunkra, és megfelelően nyitott környezetben dolgozunk, akkor megtaláljuk annak a módját, hogy meggyőzzünk másokat is a saját területünk fontosságáról. Lelkesedünk érte, másoknak szeretnénk segíteni, valamint be is szeretnénk vonni őket, hogy ők is segítsenek nekünk.

Ez egy óriási lehetőség, hiszen a belső fejlődésemhez is hozzájárulhat. Van egy részterület, amiért felelősséget érzek, ami fontos a számomra, tehát egy idő után felmerül bennem a kérdés, hogy hogyan tehetném ezt mások számára is fontossá. Természetesen nem sajátíthatok ki teljes mértékben a magam számára egy részterületet, hiszen egy cégben, egy közösségben egy közös terméken dolgozunk, ezért nem marad más választásom, mint a többiek bevonása a saját munkámba. A saját részterületem kapcsán meg kell hallgatnom a többiek visszajelzéseit, és természetesen be kell másokat is engednem a „területemre”.

A PO-t is meg kell tudnom győzni, hogy az adott részterülettel foglalkozzunk a sprintben, hogy erre is aljlokálunk időt. (Egyébként, érdekes módon, ha valami nagyon fontos a csapatnak, akkor nem kell hozzá taskot sem létrehozni, az valahogy magától is elkészül… Ezzel ellentétben ha a csapat motiválatlan, akkor a legegyértelműbb, legapróbb, egyébként 5 perc alatt elvégezhető feladatot is bele kell tervezni a sprintbe.)

Konklúzió

➔ Szoftverfejlesztőként megadatott nekünk az a lehetőség, hogy hatást gyakoroljunk munkánkkal a világra. Sok száz, ezer, millió vagy akár milliárd felhasználót is elérhetünk, és számukra értéket teremthetünk. Fontos, hogy időnként a végfelhasználókkal is találkozzunk, hogy emberi kapcsolatot ápoljunk velük, de valójában az általunk fejlesztett szoftver – digitális jellegénél fogva – lehetetlenné teszi, hogy az azt használók háláját vagy elismerését közvetlenül érezhessük.

Elismerésre azonban mindenkinek szüksége van. Az őszinte elismerés azt jelenti számomra, hogy számítok, hogy fontos vagyok valakinek vagy valakiknek, hogy van értelme annak, amit csinálok, és hogy ezt személyesen közlik velem.

Még akkor is, ha a munkánkat nem az elismerésért végezzük, nagy szükségünk van rá.

Az agilis szervezetekben az önszerveződő csapatok hozzák meg a döntéseket. Az a jó csapat, amelynek a tagjaiban sikerül az egységérzést kialakítani. Azonban az egységen belül az egyes csapattagok számára saját felelősségi kört, egy saját játszóteret, szakterületet érdemes kijelölni. Ha egy csapattag a felelősséget önként vállalja magára, akkor az a saját fejlődését szolgálja, és ezért az elismerést a munkatársaitól is meg fogja kapni.

Egy önszerveződő csapatban dolgozva a mindennapi munkánk során leginkább a közvetlen munkatársaink azok, akiktől az elismerést várhatjuk. Sokszor nem a főnökünk utasít valamire, mivel ő nem mindig lát bele a munkánkba, tekintve, hogy azt gyakran már mi magunk „szervezzük” a magunk számára. Ezt ne feledjük el, és segítsünk a közvetlen munkatársainknak is, hogy megtalálhassák a maguk számára azt a területet, ami a fejlődés ígéretével kecsegtet számukra.

Egymás vezetőinek kell lennünk.

Az Agiluu támogatja a szervezeteket, hogy agilisabbá váljanak.

Tetszett az írás? Iratkozz fel a blogra, hogy mindig értesülj az új írásokról!