Az Invitech CRM csapatának agilis útja tökéletes mintája annak, hogy milyen kicsi külsős beavatkozással milyen messzire tud jutni egy csapat az önszerveződés, az agilis, rugalmas, ügyféligényekhez alkalmazkodó működésmód útján. A közös munkánkról készült esettanulmány nemzetközi publikációja (https://www.sfio.org/interaction/2020-1/agile-transformation-with-an-agile-process/ ) elnyerte a közönségszavazatok alapján az EODF szakmai sokszínűség és bevonás díját. Ez a projekt nyilván nem csak arról a 3 hónapról szól, amíg én, mint tanácsadó, külsős agilis coach ott voltam. A csapat agilis útja nem akkor kezdődött és nem is ott ért véget- csupán azt értük el együtt 3 hónap alatt, amit legjobb reményeink szerint 6 hónap múlvára mertünk megálmodni.
A csapat ment tovább a maga önfejlesztő útján, és nem is akárhogyan: 9 hónappal később elnyerték az Év Agilis Csapata 2020 díjat. Pont egy évvel ezelőtt kezdtük a közös munkánkat. Megkértem a projekt vezetőt, Zsuzsit, hogy legyen a vendég szerzőnk és írjon ő egy blogbejegyzést arról az időszakról, ami már nélkülem zajlott, és ami a díj megnyeréséig vezetett: mi történt azóta a csapattal, hogy halad az agilis transzformáció teljes belső IT szinten, vagy Invitech szinten.
Papp Zsuzsanna:
Élet a tanácsadó távozása után
Nem lenne igaz, és talán hihető sem, ha azt mondanám onnan már minden könnyen ment, hogy nem voltak hullámvölgyek, és az Év agilis csapata cím elnyeréséig nyílegyenesen vezetett az út (és azt sem állítom, hogy az utunk végére értünk 😊)
Nehézségek, mint tanulási lehetőségek
Rengeteg olyan nehézséggel találkoztunk az elmúlt hónapokban, ami tanulási lehetőségeket kínált.
Ezt azért tartom fontosnak kiemelni, mert annak, hogy a nehézségeket tanulási lehetőségként éltük meg, hatalmas a szerepe van abban, hogy egy magas színvonalon teljesítő csapattá váltunk. A teljesítményünkhöz és ahhoz, hogy kiérdemeltük az Év agilis csapatának címét 2020-ban, véleményem szerint nagy mértékben hozzájárult, hogy sokat beszélünk mind a mai napig a hibákról. Merünk beszélni egymással és egymásnak arról, ha valamit elrontottunk vagy nem úgy sikerült ahogy azt szerettük volna. Mert nem azt érezzük benne, hogy ez egy kockázatos dolog, ciki, vagy hogy mit gondol majd a másik. Ez azt jelenti számunkra, hogy jobbá akarunk válni, és legközelebb ezt (még) jobban csinálni.
Tényleg lehet hibázni? Lehet.
A „lehet hibázni” adta pszichológiai biztonság óriási potenciált ad a fejlődésnek (mind a mai napig) mert ezáltal merünk kísérletezni, új ötleteket bedobni, melyek közül van, amit kipróbálunk, van, amit nem, van, ami beválik, van, ami nem (kvázi hibázunk).
Ahhoz, hogy ez a csapat kultúrájának részévé váljon fontos volt, hogy az „vezető” pozícióban levő csapattagok (például agilis csapatvezető vagy a fejlesztési vezető) is vállalják, ha valami nem úgy sikerült nekik sem, ahogy kellett vagy szerették volna. Ezt azért emelem ki, mert nekik egyfajta norma formáló szerepük is van, és a viselkedésükkel „bevállalásukkal” felhatalmazták a csapatot, indirekt módon tanították őket arra, hogy hibázni ér.
Azért és úgy lettünk sikeresek, mert képesek vagyunk az egyén és csapatszintű reflexióra, őszintén és transzparensen értékelni magunkat és tanulni a hibákból.
A csapat légkör sohasem volt rossz, azonban voltak (korábban természetesnek hitt) ellentétek és feszültség a csapattagok között:
· A projekt vezető számon kérte a fejlesztőket,
· a fejlesztő szerint az elemző nem ért a rendszerhez,
· a szakmai vezető szerint a projekt vezető ne várja el, hogy 1 hét alatt kész legyünk stb.
Felelősség párban a lehetőséggel
Azonban mikor átálltunk az önszerveződő, „miénk a közös felelősség és a lehetőség a változtatásra”, bevonó, felhatalmozó módszertanra, akkor elkezdett a légkör is megváltozni. Közös lett a cél, közös lett a hiba, közös lett a csúszás, mindenki ugyanazt akarta és most már nem egymással vitázva, hanem egymást segítve.
Az önszerveződés következményeként a csapat kohézió szinte megbonthatatlanul erős lett, amit óriási öröm meg- és átélni. Kialakult egy konstruktív vitakultúra a csapatban – építünk egymás gondolataira („Nekem erről az jutott eszembe, hogy..” , és mi lenne, ha ezt tovább gondolnánk azzal, hogy”. )
Mostanra nagyon jó lett a légkör a csapatban, mert a megoldásorientáltság, egymás segítése és egymás megértése fontos lett mindenkinek. Az is segített, hogy megtanultuk egymást dicsérni is 😊.
A kezdeti időszakban elég sok ellenállás volt a csapatban magával az új működési móddal kapcsolatban, ez okozta a legelső konfliktusokat. Erre jó példa, a reggeli megbeszélések (stand-up-ok) rendszere, ami nagyon nehezen indult, felesleges időtöltésnek tűnt, de idővel a kollégák maguk is meglátták annak értelmét és hasznát, hogy ez miért is jó és szükséges. Alapvetően a módszerünk, hogy „adjunk egy kis időt” az új dolgok kipróbálására, aztán adjunk lehetőséget a csapatnak és egymásnak, hogy alakítsunk a működési módon és az együttműködésen. Szintén probléma volt az üzleti területtel a feladatok priorizálása, amelyben nem nagyon hittek, de idővel sikerült bebizonyítani, hogy ez a helyes és a hatékony út. A konfliktusok kezelésében a harmadik eszközünk az egymásba vetett hit és bizalom, amit következetességgel párosítunk, illetve egy olyan légkört biztosítunk, ahol van tér és lehetőség a problémák át- és kibeszélésére.
Jó, hogy mások vagyunk
Sokat fejlődtünk abban is, hogy mit kezdünk a csapaton belüli diverzitással. Az, hogy mások vagyunk (nagyon) még nem jelenti azt, hogy kihasználjuk a különbözőségünkben rejlő potenciált. Hónapról hónapra bontakozott ki az, hogy egyre jobban be merték hozni az egyének az eltérő gondolataikat vagy épp tulajdonságaikat, amik korábban kockázatosnak, „oda nem illőnek” tűnhettek, és ezekből újabb erőforrásokat tudtunk kovácsolni. Ide kapcsolódóan emelném ki azt is, ahogy kibontakozott a tudásmegosztás kultúrája, a csapat saját tudásmegosztó fórumot vezetett be és üzemeltet, amik csapattagok által egymásnak tartott oktatásokban és szakmai show&tell session-ökben ölt formát. Korábban számos fejlesztési feladattípusra volt jellemző, hogy csak 1 ember tudta kezelni, megoldani, a tudásmegosztó fórumainknak köszönhetően ezt a kitettségünket csökkenteni tudtuk. A korábban nagyon nehezen delegáló vezető fejlesztő képes volt elsajátítani „tudásmegosztás hatalom” elvét.
A csapat minden tagja elsajátította és magáévá tette az agilitást. Nem az eszközöktől vagyunk agilisak, hanem a gondolkodás módunk és hozzáállásunk által. A korábbi ad hoc szállítások helyett rendszeres, csúszás nélküli havi fix szállításaink vannak. A korábban vaskalapos fejlesztők (is) rugalmason kezelik egy gyorsan reagálnak a változó üzleti igényekre / scope-ra. Folyamatos a haladásélmény, a felhasználók minden hónapban kapnak valamilyen fejlesztést vagy javítást, ami olyan mértékű, hogy a következő hónapig meg tudják szokni, tanulni.
Na de mit szól ehhez az üzlet/az ügyfél?
Az üzleti területek is elkötelezetté váltak a projekt és az agilis gondolkodásmód iránt. Fázisokban, működőképes, 4 hét alatt leszállítható alkalmazás funkciócsomagokban gondolkodnak
- Velük együtt finomítottuk, és finomítjuk hónapról hónapra a működésünket és folyamatainkat
- Üzleti érték alapján priorizálnak, a legmagasabb üzleti előnyt / hasznot létrehozó igények és követelmények kerülnek a backlog lista tetejére
- Emellett megjelent az igény, hogy a többi, belső fejlesztési projektünket is vizsgáljuk meg, miként tudnánk az agilis megközelítés eszközeivel hasonló hatékonyság javulást elérni
- Bizalom és partnerség: a kezdeti szkepticizmust rövid idő alatt sikerült csökkenteni, az átláthatóság javításával és a folyamatos fix szállításokkal kivívtuk a bizalmat után. Ők is hajlandóak lettek változtatásokat bevezetni annak érdekében, hogy a közös munka hatékonyságát növelni tudjuk. Pl. tesztelés fix időablakban, priorizáló megbeszélésekre való felkészülés, folyamat interakciók – visszajelzések
„Egy jól teljesítő, magabiztos IT-val hatékonyabb az együttműködés, mint a létéért küzdő, a határidőket nem tartó csapattal. Az általános hangulatot és a haladás élményt hatványozottan javította az IT-s kollégák érezhető büszkesége, hogy jól teljesítenek az üzlet legnagyobb megelégedésére” – Sales Support vezető
Lépjen hátrébb a projekt vezető és akkor mi lesz?
Az én személy szerinti szerepem tovább „csökkent” a csapatban, és egyre inkább csak „shadowing” üzemmódban vettem részt „groomingokon, stand up-okon, heti státuszokon, retrókon”, kvázi még felügyelve, hogy rendben mennek a dolgok. Ez a csapatnak is egyfajta biztonságérzetet adott, hogy még ott vagyok, tudok mindenről és ha kell döntést hozok.
Az egyes megbeszélések után az érintett csapatagokkal még pár hónapon keresztül rendszeresen alkalmaztam a megerősítő visszajelzéseket. Később aztán tudatosan elkezdtem a döntéshozataloktól is visszavonulni és engedni a csapatnak, hogy ők döntsenek, nélkülem. Magában a döntéshozatali folyamatban kérdésekkel segítettem őket, de a végen a döntést nem én, hanem Ők hozták meg.
Az üzleti oldal támogatása és a működésmódunk elfogadottsága teljesen mértékben megszilárdult és az üzleti oldal is „megtanulta az agilitást”. Fülig érő mosollyal hallgattam shadowing -ba az egyes groomingokon, ahogy az Üzleti szereplők „győzködik” egymást az üzleti igények prioritásáról. „Ennek az az üzleti értéke a cég számára”, „Ezzel azt veszítjük, ha nem lépjük meg „ , „Jó az én igényemnek ennél jóval kisebb az impaktje, én erről most akkor lemondok”.
-----------------------------------------------------------------------------------------------------------
Elképesztően szép azt látni, hogy Zsuzsi pontosan ugyanúgy lépett közelebb a csapathoz, majd lassan távolabb tőlük, ahogyan azt én tanácsadóként, coachként, mentorként tettem. Mint kiderült, Zsuzsi azóta már más projekteket vezet, és oda is viszi magával a módszertant, az Invitech belső IT-ján egyre több csapat kísérletezik a saját agilis útjának megtalálásával, nem ritkán az üzleti terület, az ügyfeleik kérésére. Persze nem csak Zsuzsi dolga a jól működő mintázatok elterjesztése, hiszen a fejlesztők is dolgoznak más csapatokban, a business analist is facilitál retrospektíveket más témákban is: lassan, de biztosan terjednek a jó gyakorlatok.