Láss tisztán, ne csak nézz!

Az egyik legnehezebb feladat ha emberekkel dolgozol, hogy mennyire engeded őket közel magadhoz. Bármilyen pozícióban is dolgozol, ez mindig nehéz kérdés. Egy olyan szervezetben, ami emberközpontú, ott meg aztán pláne.

Az évek során azt hiszem megjártam minden szintet ebben a témában és tanultam belőle.
Hogyan tudsz úgy hiteles lenni, ha nem engeded magadhoz közel az embereket? Hogyan döntesz szituációkban és problémákban, ha túl közel vagy hozzájuk? Ha túl távol vagy hogyan leszel megértő?

Én azt gondolom, hogy egy egyensúlyt kell megteremtened. Kell, hogy tudják az emberek, hogy számíthatnak rád, de ha nagyon közel vagy hozzájuk, nem tudsz racionális döntéseket hozni, elvakíthatnak az érzelmeid. 

Sok esetben a mi szakmánkban meg kell hozz olyan döntéseket, amikor a racionális gondolkodásodra és az objektivitásodra van szükség. Az érzelmeid nem vehetnek részt ebben. A legrosszabb amikor egy csapat érzelmileg befolyásol és emiatt nem látod a valós problémákat. Egyszer csak elkezded te is azt képviselni, amit a csapat fúj. 

Azt gondolom mindig van lehetőség belülről javítani a dolgokon.

Sok retrospektíven ültem már, ahol a problémák okozói – a csapat által gondolva – valamilyen külső probléma. Amikor megkérdezed, hogy oké, de mi mit tettünk azért, hogy máshogy legyen? A válasz: semmit.
Hiszek abban, hogy mindig van ráhatásunk a közvetlen környezetünkre, ha más nem egy kis mantrázás mindig segít.

Általában egy csapat és egy vezető (vagy csapat csapat) teljesen máshogy látja ugyanazt a problémát. Emiatt én mindig azt vallom kérdezd meg mind két oldalt és érveljen a saját gondolatai mellett. Ha valaki nem tud érvelni, azt nehéz komolyan venni. Mégis ilyenkor hogyan oldod meg a problémát?

Fontos, hogy te egyik oldalra se állj be, akár mi is a saját gondolatod. Fontos, hogy ki tudj lépni a problémából és távolról tudj ránézni a szereplőkre. Csak ezután mehet a megoldás. Hogyan jön képbe az érzelmi bevonódás?Szerintem ha túl közel állsz vagy a vezetőhöz vagy a csapathoz, nem tudsz objektíven gondolkodni. Fontos ez nem azt jelenti, hogy ne legyen jó kapcsolatod az emberekkel, csak tudj nehezebb helyzetekben racionálisan és objektívan gondolkodni.

A szoftverfejlesztés világában a minőségbiztosítás egy elengedhetetlen feladat. A tökéletes világban mindenre van egy pozíció és egy ember, aki elvégzi az adott feladatokat. Telepítés, code review, dokumentáció, automata teszt… biztos mindenkinek ismerős. Tipikus standard probléma, hogy mi azért nem tudunk jó minőségű szoftvert gyártani, mert nincs ez, nincs az, vagy amaz. Nem állítom, hogy nincs ezekre szükség, de néha a szervezet nem áll még ott, hogy emberekben vagy infrastruktúrában, technológiában mindezt tudja támogatni.

Az emlékezetes példát nézve, ami jó pár éve történt, a szervezet méretéből adódóan nem tudott erőforrást allokálni arra, hogy a minőségbiztosítási feladatokat külön személyek lássák el, ezért ezen feladatok ellátását a csapatokra bízta. Minden retrospektív arról szólt, hogy venni kell fel embert, mert másképp nem tudjuk a minőségbiztosítási feladatok ellátását megoldani. Mivel mindenhonnan ezt hallottam elballagtam a vezetőhöz, akinek ráhatása lehet erre a dologra.
Előadtam a problémát, amit meg kellene oldani, majd meghallgattam az ő véleményét is, ami persze nem egyezett a csapatokéval. Őszinte leszek elsőnek nem értettem és bosszús voltam, amiért nem sikerült a csapatok problémáját megoldani. A vezető véleménye az volt, hogy a minőség nem fontos a csapat számára, ezért nem végzik el ezeket a feladatokat. Úgymond “büdös” mindenkinek.
Tény, hogy egy szoftverfejlesztőnek a tesztelés nem lehet a legvonzóbb feladat, viszont a kezéből kiadott munkáért a csapat a felelős. A hibát ott követtem el, hogy csak a csapatok állás pontját tudtam képviselni, miközben én személyesen sem értettem a programozói múltamból adódóan, hogy miért fáj ennyire 2 hetente egy minőségi tesztet végig nyomni vagy reviewzni érdemileg a másik munkáját? Teljesen egyértelmű, hogy olyan professzionális sosem lesz, mintha egy képzett szuper tesztmérnök nyomkodná végig, viszont legalább próbálunk tenni azért, hogy amit kiadunk az ügyfélnek, az valamilyen szinten lehetőleg ne banális hibákkal menjen ki. Nagyon szerettem a srácokat, együtt lélegeztem velük, csak a jót akartam nekik.

Itt rontottam el. Teltek a hetek és rájöttem, hogy lehet meg kéne jobban értenem a vezetői oldalt is. Tulajdonosi szemlélet… egy szép szó, amit többször emlegetünk, ha egy csapatról van szó. Ahogy néztem a csapatokat, ahogyan arról beszélnek, hogy nekik ez mekkora teher, rájöttem, hogy elrontottam. Egyszerűen nem hívtam fel a figyelmet a másik fél gondolataira. Ott volt X csapat, akik nem szerettek volna csinálni valamit, de alternatív ötlet csak az volt, hogy vegyünk fel embereket, akik majd ezeket a feladatokat ellátják. Persze azt senki nem értette meg, hogy nem tart ott a cég, hogy teljes külön tesztelői csapatot tartson fenn.

A fő gondolat, ami megváltozott bennem az az, hogy elviekben olyan csapatokat szeretnénk nevelni, akik vállalják a felelősséget a termékük minősége kapcsán. Leültem velük és beszéltünk arról, hogy ha ezeket a feladatokat nem végezzük el, akkor a kiadott termék minősége lesz kockáztatva, ami a mi felelősségünk. Sikerült egy olyan helyzetet teremteni végül, amiben a csapatok is és a vezető is tudta képviselni az álláspontjait és egy közös szerződés született arra, hogy milyen feladatok ellátására van szükség a minőségbiztosításához.
A lényeg, hogy simán elvakítottak a csapatok, akikkel a mindennapjaim éltem. Nem az ő hibájuk, én nem vettem észre a többi tényezőt.
Mit tanultam ebből? Ha egy problémánál csak egy álláspontot képviselsz és nem maradsz objektív a résztvevők körében, nem tudod a problémát se megoldani igazán jól. Manapság erre már sokkal tudatosabban figyelek. Jelenleg is dolgozom egy csapattal, viszont nem hagyom, hogy egy probléma esetében csak az ő gondolataikat lássam. Amikor mentorálok más Scrum Master-eket, Agile Coach-okat mindig úgy szoktam ezt elmagyarázni, hogy olyan ez, mint amikor a nagy mester kilökte Dr. Strange-t a saját lelkét a testéből és úgy szemlélte tovább a világot. Egy teljesen új világ nyílhat ki előtted. 

Azt javaslom, sose hagyd, hogy elvakítson csak egy álláspont. Járd körbe a problémát és maradj objektív, úgy hozz javaslatokat a megoldáshoz.

Létezik az agilitás szállítás nélkül?

Egy olyan témát fogom érinteni, amivel sok kollégám valószínűleg nem fog egyetérteni.

Létezik agilitás szállítás és eredmények nélkül? Mi számít eredménynek?

Nekem a szállítás azt jelenti, hogy tudtam értéket teremteni az ügyfelem számára, amit már ő maga is tud használni és tesztelni.
Azt gondolom bármennyire mondhatjuk magunkról, hogy agilisak vagyunk, ha ez az eredményekben nem látszik. Ha nem tudunk kész produktumot odaadni az ügyfélnek, nem tudom elképzelni, hogy jól csináljuk. Az agilitás eszközöket ad, egy keretet, amivel támogatni tudja a gyorsabb szállítást. Ha ezeket egyáltalán nem vagy nem jól használjuk, nem a célok és az értékek mentén gondolkodunk, valószínűleg nem tudunk agilitásról beszélni. 

Mindent amit teszek, azért csinálom, hogy a szervezetet előrébb tudjam lendíteni. Minél boldogabb ügyfeleink legyenek, akik gyorsan kapnak valami kézzel fogható, nyomkodható kütyüt/alkalmazást. Mindemellett célom, hogy mindezt motivált dolgozókkal érjük el.
Ha ezt nem tudom biztosítani, valamit nem jól csinálok. Ha nem adok értéket a szervezetnek vagy nem látom, hogy valós segítség lennék, nem csinálom jól.
Bármennyire lehet jó egy standup, ha közben nem esik ki produktum a csapatból hónapokon át. Persze most nagyon kisarkítottam ezt a példát, de szerintem sokan értik mire gondolok. Ha felkenünk egy mázat és nem gondoljuk át a szervezet struktúráját, érettségét, személyi kérdéseket és a többit, akkor ne csodálkozzunk, hogy nem esik ki semmi a másik oldalon.

Az első élményem, amikor ennek a fontosságára rájöttem, az egy élesítés előtti helyzetben következett be. Volt 2 vagy 3 hónapunk arra, hogy egy új rendszert élesbe állítsunk és az ehhez szükséges kritériumokat teljesítsük. Valljuk be még több sebből vérzett a dolog, akár feature szinten vagy infrastruktúra terén. Nem hittük el, hogy meg lehet csinálni, de mi mégis megcsináltuk. Felmértük mi az amin ideiglenesen most változtatnunk kell és léptünk abba az irányba. A döntést közösen hoztuk meg, hogy most erre van szükségünk ahhoz, hogy szállítani tudjunk. Vannak azok a helyzetek, amikor módszertant váltasz, de rövid időre. Mindezt csak a szállítás érdekében teszed. Sokszor elfelejtik az emberek, hogy ami működhet rövid távon, az nem fenntartható és hoz eredményt hosszabb távon.

Vegyük akár példának egy nagyon szigorú státuszolós megoldást. Kényszer helyzetben ez tud működni, amikor már egyáltalán nem látszik a haladás, de hosszabb távon nem fenntartható. Nem lesznek boldogok a munkavállalók (se motiváció, se kreativitás), nem lesz jó a vezetőnek, akinek folyamatosan kontrollt kell fenntartania az embereken és még lehetne sorolni.  

Ha egy ilyen helyzettel találkozol, szerintem 2 dologra kell koncentrálnod:
1. Rövid távon hogyan fogtok eredményeket elérni és az ügyfelet kiszolgálni.
2. Hosszabb távon mi az amin változtatni kell a jelenlegi működésedben, milyen tanulságokat vonsz le, hiszen nincs látható eredmény.

Ilyenkor mindig jönnek a kifogások, a hiszti, az egymásra mutogatás, majd szépen lassan elfelejtjük, hogy egy közös célért dolgozunk mindannyian.
A kérdés csak az, hogy hogyan állunk fel ebből a helyzetből: tanulunk belőle vagy sem?

Ezekben a helyzetekben Agilis Coach-ként másképp kell viselkedned, mint ahogy a szervezet minden tagjának is. Mindent a haladásért! Ott kell segíts, ahol tudsz.
Mindez sok konfrontációval jár és nehéz pillanatokkal, de miért is csináljuk ezt ha nem azért, hogy gyorsabb és jobb szállítást tudjunk elérni az ügyfelek felé?

Amikor elkezdődik egy transzformáció és még keresi a szervezet hogyan implementálja az új működést, felmerül a kérdés bennünk: “Nem kellene úgy csinálnunk mit régen? Úgy tudtunk szállítani.” Minden transzformációhoz szerintem időre van szükség és sokszor nehéz döntéseket is meg kell hozzunk. Azt gondolom ezen a folyamaton úgy tudunk segíteni, ha mindig a szemünk előtt tartjuk a célokat és értékeket, amit képviselni szeretnénk.

Örök igazságot nem tudok adni, viszont azaz egy biztos: hogyha nincs szállítás, akkor valamit nem csinálunk agilisan, csak annak hívjuk vagy hisszük magunkat.

Mikor érünk már oda?

Ezt a kérdést minden szülő hallotta már vagy gyerekként az autó hátsó ülésen mi is többször hajtogattuk szüleinknek utazás közben. Mindamellett, hogy idegesítő a kérdés, annak aki hajtogatja annak is nagy stressz.

Időnként azon veszem észre magam, hogy türelmetlen vagyok.
Annak idején az egyik mentorom többször mondta nekem, hogy vannak tapasztalatok, amit meg kell szerezni, amit át kell élni. Ezeket nem lehet siettetni. Több év tapasztalatát nem élhetem meg fél-egy év alatt. Mint egy durcás kis gyerek, nem akartam hallgatni rá, mert én előre és előre szerettem volna lépni.

Az elmúlt pár évben rájöttem, hogy igaza volt.
Ez a fajta türelmetlenségem megjelenik olykor egy szervezet vagy egy csapat transzformációja kapcsán is. Ilyenkor hihetetlen módon kezdek el dühöngeni magamban, hogy mi az amiért még mindig nem tud valami működni.

Miért kell 100x elmondani ugyanazt? Miért nem tanulnak abból, amit elmondtál nekik, hogy mi fog következni, mert már 100 ilyet láttál?
Ilyenkor mindig azzal nyugtatom magam, hogy ha végülis a gyereknek is ha azt mondod, hogy ne játsszon a tűzzel, mert megégeti magát, csak akkor engedi el az öngyújtott, ha már megégette a tűz.
Rájöttem, hogy nem erőszakolhatom rájuk mindazt, amit én már megtapasztaltam. Vannak olyan hibák, amiben hagyni kell akár egy csapatot vagy szervezetet, hogy elmenjen a falig. Ilyenkor egy dolgot szoktam mérlegelni: sérül-e ezzel a szállítás vagy sem? Mi az, amikor még nem fog olyan mély károkat okozni, amiből már sokkal nehezebb visszajönni.

Minden nap egy kihívás számomra, hogy kihozzam a legjobbat az emberekből. Sok szakmabeli elfelejti, hogy csak azért, mert a pozíciónk neve Agile Coach, ez nem jelenti azt, hogy bármit mondok, meg kell csinálnia mindenkinek kérdések és értelem nélkül.
Ez a szakma nem úgy működik, hogy majd én elmondom a tutit, ti meg csináljátok. Ha nem értik, vagy nem tudod elmagyarázni, hogy miért csináljon valamit másképp, mit fog ő ezzel nyerni, akkor benned van a hiba. Kivétel ez alól, ha valaki a szervezet céljaival szemben áll.

Azt gondolom első körben el kell oda juss, hogy hitelesnek tartsanak.
Mitől leszel hiteles? Feltetted már magadnak a kérdést?
Ez bizony nem jön magától, neked kell tenned érte. Meg kell mutatnod magad, hogy érdemes rád hallgatniuk. Ehhez bizony a szó kevés, kemény munka kell legyen mögötte.

Szerintem a következőktől hiteles egy Agile Coach és/vagy Scrum Master:

  • Nem csak beszél, hanem dolgozik is
  • A hozzá tartozó csapatoknál van szállítás
  • A hozzá tartozó csapatokon látszik a fejlődés (mondhatjuk, hogy a névjegye)
  • A szervezet fejlesztéssel kapcsolatos ötletei, nem csak ötletek, hanem javaslatok, megoldási tervek is
  • Ha valamivel nem ért egyet, az mellett kiáll és érvel
  • Határozott
  • És még sorolhatnám…

Ha mindez megvan, akkor jön a következő kihívás.
A gondolataim egy szervezettel, csapattal kapcsolatban már legalább egy lépéssel előrébbre áll, mint ahol ők épp tartanak. Emiatt sokszor feldühítenem magam és türelmetlen leszek, hogy miért nem tartunk még ott?

Amit tanítok nekik minden nap, hogy a sikereseket is meg kell élni, néha ha rólam van szó elfelejtem magamra alkalmazni.
Teljesen felpörget, hogy eljutok egy adott szintre és ott mintha a lépcsőn beakadna a lábam és próbálom kihúzni, de nem jön ki … valljuk be, semmi baj nincs, mert nem fogja a lábam egy cápa leharapni, csak annyi történik, hogy később érek fel a lépcsőn. Mégis, én úgy élem meg, mintha a világ legnagyobb problémája lenne.

Mondok egy példát. 
Jelenleg van egy nagyszerű Agile Coach csapatom. Az, hogy január óta hova jutott el a csapat nagyon látványos és sok mindenkinek kívánom, hogy átéljen hasonlót.
Mégis én min gondolkodom nap, mint nap? Miért “csak” itt tartunk? Miért nem lépünk már tovább? Miért nem tartunk már ott hogy…? Majd rájövök, hogy nem lehet mindent siettetni.
Van, aminek érnie kell, mint ahogy nekem is érnem kellett.
Szóval javaslom mindenkinek, hogy amikor kicsit kétségbe esve ülsz, hogy mit rontasz el, miért nem megy minden úgy ahogy te gondolod, akkor ülj le egy picit, gondolj vissza az elmúlt időszakra és értékeld újra a gondolataid. Lásd az elért eredményeket.
Lehet te is rájössz, hogy sokkal nehezebb problémákkal is már megbirkóztatok már, ezen is túl fogtok lépni, csak talán ezen az állomáson most többet fogtok elidőzni.
Viszont ha nincs eredmény, akkor mással van a probléma.

Te látod a saját eredményeid?

Csapat vagy csoport?

Csoport vagy csapat? A mi szakmánkban többször előfordul kérdésként, legalább is bennem biztos.

Mitől lesz több ember összeültetve egy csapat, nem csak egymás mellett ülő emberek kupaca? Agilisak lesznek attól az emberek, ha egymás mellett ülnek?

Szerintem nem, ha nincs közös cél, vízió és egymásra utaltság. Közös munka… mit jelent ez?
A héten teljesen más téma kapcsán beszélgettem egy vezetővel, aki segített nekem elmagyarázni milyen fejlesztési környezeteket használunk és hogyan fog zajlani a jövőben a release-elés. Ezzel a témával kapcsolatban szintén a héten egy másik Agile Coach ismerősömmel is beszélgettünk, aki ebéd közben elkeseredve mesélt nekem hogyan nem sikerül neki megértetnie az emberekkel a user story szintű release-elést. Ez elindított bennem egy gondolkodást a témáról, hiszen valljuk be találkoztam már hasonló szituációval. 

Sokszor érzem, hogy az emberek nem értik miért kell egy helyen ülniük, amikor elkezdődik az agilis transzformáció, de persze megteszik, mert ezt kérték a vezetők.  “Ettől leszünk agilisak?” – kérdezik. Erre azt szoktam válaszolni, hogy természetesen nem, ha továbbra is úgy dolgoztok ahogy előtte. Az hogy egymás mellett ültök, csak az első lépés ahhoz, hogy kicsit “szem előtt” legyetek egymásnak.

Miért számít ez? Nos nézzük csak… az a célunk, hogy az üzlet és a fejlesztés minél közelebb legyen egymáshoz. Ezt szerintem annak, aki szoftverfejlesztésben dolgozik vagy dolgozott valaha nem kell magyarázni. Hogyan is épül fel egy csapat?
Van benne üzleti szakértő, frontend fejlesztő, backend fejlesztő, tesztelő és még lehetne sorolni. Mindenki a saját területéhez ért a többiekéhez pedig semmit vagy csak keveset. Az pedig, hogy egy feladaton együtt dolgozzanak, ó hát erről szó sem lehet, “eddig sem így szoktuk”. Mindenki fogja a kis saját feladatát, eldolgozgat rajta és kész.

Nos akkor ez egy csapat? Az én olvasatomban ez elég messze van egy csapattól. Ez inkább X összeültetett ember, akik semmit nem tudnak egymás munkájáról.

Mégis hogyan lesz ebből csapat?

1. Ha teljesen külön dolgoznak továbbra is, akkor sehogy. A csapatnak kell egy cél, egy vízió, ami mentén meghatározzuk a létüket és egymásra utalással tudják elérni a közös célt.

2. Ha sikerült a célt, missziót meghatározni utána jöhet a következő lépés. Hogyan dolgozunk mi ezért a célért?
Ilyenkor mindenki elmondja hogy hát én megcsinálom a backend-et én meg a frontend-et és így tovább. No de összeérnek ezek? Jaaaa, azt nem… Általában én azt szoktam ilyenkor alkalmazni, hogy együttdolgozásra bírom őket. Ehhez nagy segítség az, ha end to end user story-kat határozunk meg.

Itt kezdődik a neheze. Hogyan csináljuk ezt?
Olyan feladatokat kezdünk el definiálni, ami átfogóan nézi az üzleti igényt, nem feldarabolva.
Vegyünk egy nagyon egyszerű példát. Én mint ügyfél szeretném egy helyen kezelni az összes könyvem, hogy mindig tudjam pontosan milyen könyveim vannak és melyikeket olvastam már el. Tudok újat felvenni, a meglévőket szerkeszteni és törölni. Hogyan lehet ezt darabolni?
A nem túl hatékony megoldás: 

1. Valaki kitalálja hogyan nézzen ki a felület.
2. Valaki lefejleszti a tárolt eljárásokat és az adatbázist táblákat, ahol tároljuk az adatokat és amik segítségével visszakérdezzük az adatokat.
3. Valaki megcsinálja a controller-eket és a html-t, ami megjeleníti a grid-et.
4. Valaki design-olja az elkészült oldal.
5. Végül jön egy tesztelő, aki szétszedi az egészet.

Hol van itt a csapatmunka? Mindenki a kis szeletével amikor elkészült, azt tovább adja a másiknak és közben eltelt 2 hónap. A megrendelő ha ránéz, közli velünk, hogy “én nem ezt kértem”. Ez egy tipikus példája annak, hogy ugyan egymás mellett ülünk, de inkább csoportként, minthogy csapatként.

Hogyan csináljuk ezt csapatként?
Én, mint aki hozza az ügyféligényt szólok a srácoknak, hogy van egy új feladatunk (az még jobb ha maga az ügyfél is jön velünk). Elmondom nekik, hogy mit kéne csinálni és közösen kitaláljuk hogyan tudunk ebből bármit is minél hamarabb megmutatni (MVP szemlélet) és hogyan tudjuk darabolni. Mint ahogy láttuk fenn is nem az lesz a megoldás, hogy szétdaraboljuk azokra a részekre, hogy ki mihez ért. Így semmi esélyünk arra, hogy együtt dolgozzunk.

Csinálunk olyan feladatokat, ami nem csak egy embert, hanem az egész csapatot érinti.

A user story-nk az, hogy megjelenítjük a grid-ben az adatokat és lehet új elemet felvenni. Simán befutható 2 hét alatt és még az ügyfél is boldog lesz, ha láthatja hol tartunk. Tehát neki látunk együtt, kénytelenek leszünk egymásnak segíteni. A backend fejlesztő nem tudja a frontend fejlesztő nélkül megcsinálni a munkáját, muszáj egyeztetniük ki hogyan képzeli el az összeérést. Ez igaz mindenki másra is. Máris hirtelen van értelme annak, hogy egymás mellett ülnek az emberek. 

Jönnék egy házépítős példával (aki ismer tudja hogy ezeket szeretem, az autós példák túl férfiasak). Van egy kőműves, egy ács, egy villanyszerelő és a többi. A háztulajdonosnak az lesz a célja, hogy minél hamarabb kész legyen a háza.
Hogyan fog a leggyorsabban felépülni a ház? Remélhetőleg akkor, ha ők összedolgoznak és beszélnek egymással. Ha fogalmuk nincs egymásról, hogy hogyan állnak épp, nehéz lesz azon dolgozni, hogy minél gyorsabban befejezzék a munkát. Várnak egymásra heteket, emiatt a tulaj meg már kitépte a fél haját. Mi a célja az összes munkás embernek? Az, hogy a ház felépüljön.
Hogyan érik ezt el a leggyorsabban? Ha összedolgoznak, nem akkor ha egymásra várnak és fogalmuk sincs, ki hogyan halad. A jéghegy csúcsa, ha véletlen még egymásnak is besegítenek, ha csúszás van, mert érdeklődne nézi mit csinál a másik és hogyan tudna neki segíteni, hogy beérjenek a célba minél hamarabb. 

Nos ez az, amikor már csapatról beszélünk, nem csoportról. Amikor tűzön vízen át segítenél a másiknak, még ha nem is értesz annyira hozzá, hogy beérjetek a célba. Ha kell nekiállsz tesztelni, vagy elkezded tanulni a másik munkáját.
A lényeg, hogy ha valaki lemarad vagy elakad odaálltok mellé és húztok együtt a cél felé. Néhányan azt mondják ez sokkal hatékonyabb és gyorsabb szállítást hoz magával, ahol az ügyfél is boldog. Az eddigi tapasztalataim alapján egyetértek.
Az élmény, amikor pár ember elkezd csapatként működni, csodálatos érzést kelt bennem. Erővel teli tankként törnek előre. Nekem ezt jelenti csapathoz tartozni.

Neked mit jelent?

Te miért csinálod?

Megéri véresen komolyan dolgozni? Teremtek értéket a munkahelyemen minden nap? Van eredménye annak, amit csinálok?

Hetek óta ezek kavarognak a fejemben.

Az utóbbi időben sok kollégámmal beszélgettem, akik ezt a kérdést tették fel maguknak és nekem is. Agile Coach-ként vagy Scrum Master-ként nagyon nehéz megmondani és átadni bárkinek is, hogy te hogyan teremtesz értéket, mert ez nem olyan, mint amikor leülsz kódolni és egyszer csak megjelenik egy alkalmazás előtted, majd elönt a büszkeség érzése, hogy igen ezt én írtam a két kezemmel. 

Több mint 5 éve élek az agilis szoftverfejlesztés világában, amit egyszerűen imádok. Elsőnek imádtam, hogy fejlesztő lehetek és hogy minden nap alkothatok valamit, majd beköszöntött az életembe egy teljesen új világ.

Amikor alkotsz, de emberekkel… nem kódsorokkal.

Kicsit olyan lettem tőle, mint egy drogos, akinek több és több kell folyamatosan ebből az új szerből. Szépen lassan lecseréltem a billentyűzetet és elkezdtem emberekkel alkotni.
Hogy lesz nekem hozzáadott értékem mégis ehhez az egészhez? 

El kellett telnie egy kis időnek mire rájöttem hogyan működik. Ez nem olyan, hogy folyamatos azonnali visszajelzést kapsz a munkádról, amit alkotsz nap mint nap, hanem sokkal hosszabb távon jön a visszacsatolás. Ezt elég nehezen dolgoztam fel, viszont amikor elérkezett baromi jó érzés volt, egyre többet és többet akartam ebből. 


EMBEREKEN SEGÍTENI.

Valahogy belém kódolodott az évek alatt. Mindennél jobban erre vágyom. Látni, hogy valamibe rengeteg energiát adsz és meg lesz az eredménye az borzalmasan jó érzés, teljesen bepörgök tőle.

Az első ilyet évekkel ezelőtt éreztem, amikor 1 éve dolgoztam már egy nagyon nehéz helyzetben lévő csapattal, akiknél már mindent megpróbáltam, hogy hatékonyabban tudjanak dolgozni, de nem sikerült eredményt elérnem. Minden retrospektív után úgy mentem haza, hogy hol rontom el? Hogyan nem sikerül előrébb lépnünk? Majd egyszer csak megtörtént. Egyszerre minden megváltozott. A srácok megfogadták a tanácsaim és egyre feljebb és feljebb törtek, majd ott tartottunk, hogy ők az egyik legjobban szállító csapat a cégnél. Én csak ámultam bámultam és iszonyatos büszkeség töltött el. Nem adtam fel, meg mertem döntéseket hozni és annak vállalni a következményeit és meg lett az eredménye.
Hol volt a hozzáadott értékem?

Nem én tettem le a kódsorokat az asztalra, nem én voltam aki rákente a téglára a maltert, de én voltam aki segítette a ház építését a vezetőkkel együtt. Nélkülük nem ment volna. Akik segítettek mit hova tegyünk, hogy a csapaton belül hogyan rendezzük soraink. Boldog voltam. Most ugyanezt látom. Új cég, új élmények, új kihívások. Nem mindig könnyű sokszor elég mély ponton vagyunk többen is, de akkor megtörténik a pillanat… ami mindig tudja mikor jöjjön el. Nem kell sok hozzá. Elég egy jó kis refinement hozzá vagy csak egy agilis érettséget felmérő eszköz átbeszélése a csapattal, ahol azt érzed, hogy minden klappol. A srácok megértettek mit papolsz nekik hónapok óta, értik miért jó nekik, látják, hogy sokkal produktívabbak tőle és mindennek a csúcsa amikor vissza is jeleznek neked: “Köszi Petra!” 

Na ez az a pont amikor azt érzed értéket teremtettél. Amikor lehet, hogy fájdalmas hónapokon mentél át, azt érezted, hogy nem sikerül eredményeket elérned, majd egyszer csak elkezded élvezni, ami megtörténik körülötted. 


Mindezért milyen díjban részesülsz te? El kell keserítenem, nem te fogsz díjakat kapni egy ünnepségen, hanem a csapatod. Ez olyan, mint a foci. Egy jó edző nélkül sosem fognak meccset nyerni az emberek, viszont a csapatot ünnepeljük, hiszen az edző tanácsai alapján ők játszák le a meccset. Te mindig a háttérben maradsz, ezért magaddal rendben kell legyél, hogy tudd neked mi szereped volt az adott meccs megnyerésében.


Nem azzal tudsz Agile Coach-ként értéket teremteni, hogy pakolod a téglát. Azzal fogsz, hogy a téglát pakoló személynek – képletesen értve, senki meg nem bántva – segítesz rámutatni arra, hogy talicskával egyszerre több téglát tud elvinni A pontról B-be, arról nem is beszélve ha ketten pakolják a téglákat gyorsabban haladnak. Az tölt fel és ott érzem, hogy értéket teremtek, hogy látom a csapaton/szervezeten, hogy honnan hova jutott és mindezt a te segítségeddel érték el. Néha ez csak annyi, hogy leülsz 1-1 beszélgetni valakivel, akinek tudtál megoldást adni a problémájára, máskor meg határozottan közlöd valakivel, hogy sz*r az amit csinál és nem célravezető, ha az adott irányba megy tovább. 
Mindez csak akkor fog működni, ha hiszel magadban és látod magad előtt az eredményeid. Máshogy nem fog működni. Szóval fel a fejjel, nem szabad feladni a kemény munkának mindig meg lesz a gyümölcse 🙂