Avagy a szervezetfejlesztési orosz rulett.
Mielőtt mindent elsöprő lendülettel belevágnánk a feladatba, fel kell tenni A KÉRDÉST (így, csupa nagybetűvel): „Vajon mennyire irtotta ki az emberek fejéből az újra való nyitottságot, a kreatív kísérletezés iránti vágyat a multik KPI-vezérelt, szigorúan hierarchikus és számoktól/kimutatásoktól kísértett légköre?” – és meglepődni.
Sokan, sokféleképpen közelítik meg ezt. Van aki eleve egy Agile Readiness Audittal kezd, vagyis jól megszerkesztett kérdésekkel, átgondolt szempontok szerint sorolja be az ügyfelet, így kímélve önmagát az esetleges kellemetlen meglepetésektől.
Ha erre nincs meg a tér, akkor is érdemes végiggondolni, mi történhet a folyamat során.:
A feladat:
Lesznek olyan forgatókönyvek/minták, amik időről időre ismétlődnek, és lesz ami cég-specifikus. Ilyen minta például, hogy minél régebben csinálnak -hagyományos munkamódszerekkel és teljesítmény értékelés mellett- a csapattagok egy adott feladatot, annál nehezebben nyitnak bármilyen változásra, így például az Agile Manifesto pontjai felé. Persze, ha kiadják nekik utasításba, maradéktalanul betanulják és álmukból felkeltve is el tudják mondani, hiszen így szocializálódtak:
„Adjatok nekem egy fix pontot (KPI) és kifordítom sarkaiból a világot!” – Arkhimédész, középvezető
Viszont az Agile maga, nagy százalékban mindset és mint olyan, nehezen mérhető. Persze lehet ráhúzni Velocityt -ha jól alkalmazzák, mérhetően gyorsabban/kiszámíthatóbban/ütemesebben szállít majd a csapat potenciálisan élesíthető készterméket.
Ebbe a képbe azonban belerondít az ún. Alapvető Attribúciós Hiba (leánykori nevén megfeleltetési torzítás). Egyszerű példával élve ez olyan mintha siker esetén azt mondanák „Persze hogy sikerült, hisz megtettünk mindent és keményen dolgoztunk”, sikertelenség esetén pedig azt „Ha nem kellett volna erre a módszertani bevezetésre pazarolni az időt, akkor nem csúszunk meg!”… Maga a „siker” fogalma is elég tág és szubjektív ahhoz hogy kedvünk szerint alakítsuk mikor nevezzük magunkat sikeresnek, de ez már egy külön bejegyzést érdemelne.
Keresztfunkcionalitás, „pont elég jó”:
Innentől úgy folytatom, mint a Mátyás király mesében: nyújtok is megoldást, meg nem is. Ha elfogadod a tényt hogy a tanulási ciklusok folyamatos futtatásán és ezen ciklusok ciklusidejének rövidítésén kívül nincs jól algoritmizálható eljárás, (nincs silver bullett), máris kevésbé fáj. Ehhez a tanulás iránti vágy előfeltétel. Ha az emberek egyénileg már mindent tudnak (szerintük), akkor csak a búgócsiga üzemmód van egy Scrum Master számára, ami egy darabig búg, mondja és mondja és mondja…. aztán megáll ugye.
Szóval Először is tudnod kell, mit vársz a csapattól.
Tegyük fel, hogy egy kereszt funkcionális (ám cross-kompetencia nélküli!!!), különböző területek szakértőiből álló csapatot (ún. senior team) akarsz Scrumban dolgoztatni. Egy ilyen csapatban a csapattagok jelenlegi tudása -külön külön, egymás mellé állítva- lefedi a teljes jelenlegi értékláncot a megrendeléstől a szállításig, ám kicsi a közös metszetük. Tehát mindenki szakértő a maga területén (sales, development, marketing, kávéfőzés), de egymásnak csak addig tudnak segíteni, amíg az agilis tart, azaz amíg a probléma és/vagy a megoldás nem lett feltárva agilis eszközök segítségével. Ha megvan a probléma és rá a legjobb tudásuk szerinti -pont elég jó- megoldás, onnantól már nem tudnak segíteni, feladatokat nem tudnak átvállalni, hogy felgyorsítsák a megoldás megvalósítási folyamatát. (Más eset, ha a csapattagok fejlesztenék a tudásukat, értelemszerűen lehetne a „pont elég jótól” jobb megoldást találni.)
Megkötések:
Ha ilyen környezetbe csöppensz, valószínűleg erős megkötésekbe fogsz ütközni. Megkötés alatt értem, hogy egy senior nem hajlandó sem az idejét, sem a figyelmét alanyi jogon Neked, a Coachnak „ajándékozni”. Ha mindez azzal párosul, hogy a kísérletezést zsigerből elutasítja -mert a bevált munkamódszereiben hisz-, akkor vagy észreveszed az igényeit és minél hamarabb, minél pontosabb megoldást (agilis technikát) javasolsz, vagy idővel megkérdőjelezi a létjogosultságod, mint csapattag. Cross-kompetencia teljes hiányában nincs igazi csapatjáték, és ezért az orosz rulett:
Ha egy focicsapatot úgy állítok fel, hogy a hátvédek távolugrók, a középpályások sakkozók, és a csatárok űrhajósok, akkor a csapat veszíteni fog nagyjából bármilyen amatőr focicsapat ellen. Ha nem focit játszanak, hanem sakkal kombinált távolugrós űrhajósdit, akkor sem azért nyernek majd, mert jó csapatot alkotnak, hanem mert más nem tud ilyen játékot játszani. Nem az összekapaszkodás miatt lesznek sikeresek. Az ilyen csapat csak addig tud összekapaszkodni, amíg megismerik a szabályokat, és kitalálják a legjobb egyéni stratégiákat a győzelemhez vezető úton.
(Rész)megoldás:
Ilyenkor megoldás lehet, ha a termékfejlesztés kezdeti szakaszában (amíg minden alakul, ismerkednek a szabályokkal) mindenhol ott vagy, fogod a kezüket… idővel pedig félre állsz:
Csapat szinten megfogalmaztok egy Project Goal-t, ami addig tartson, amíg a kérdésre adott lehetséges variációk köre le nem szűkül pontosan egyre (esetleg A-B teszt esetén kettőre). A cél eléréséig hátralévő dolgokat használható Backloggá (kézzel fogható User Storykká) alakítjátok, majd néhány sprinten keresztül tartjátok a Sprint Ceremonykat (NAGYON NAGYON ERŐSEN FACILITÁLVA!!! – és persze mégsem érezheti a csapat azt, hogy rájuk erőszakoltad magad mint holmi agilis evangelista).
Pro Tipp: Ilyen, frissen alakult csapatoknál a Team Norms megbeszélése és Sprint Goal mellé, jól látható helyre való kifüggesztése akkora segítség lesz, mint mikor Quake 3-ban beírtad a kódot a final boss ellen. FONTOS: Team Norms csakis egyetértés és megegyezés (team agreement) után kerülhet ki! Ennek hiányában nem fogják sajátjuknak érezni, te leszel a diktátor, és tudjuk mi jár az ilyen vezetőnek.
Apropó, friss csapat: végig kell járniuk a Tuckman modell minden fázisát (Forming->Storming->Norming->Performing). Semmi nem biztosítja hogy egészen a Performing-ig velük leszel, így tényleg fontos hogy figyeld a ki (nem) mondott igényeket, és a lehető leghasznosabb tanácsokkal lásd el őket.
A tanulásra nem nyitott emberekkel nem lehet coach módban kezdeni semmit. Ők ugyanis kézzel fogható eredményeket akarnak, azonnal. A coach segít a fejlődésben, támogatja az új dolgok kipróbálását, és segít leszűrni a tanulságokat. Ha valaki nem akar mindset-et váltani, csak túl akar lenni a feladaton anélkül hogy leszednék a fejét a nem elég jó végeredményért, akkor ott az agilis segítő nem fog tudni érvényesülni.
Szimptóma: bármit mondasz, ők már ezt hallották valamelyik „kötelező HR-es tréningen”…. Rosszabb esetben hatszor.
…Ennek ellenére ha ügyes vagy, tudsz segíteni az agilis mindset felé vezető úton haladni még azoknak is, akik nem akarnak menni rajta. Persze nem közvetlenül, csak közvetve:
Példa #1:
„Active listening game-eket” játszatva értesd meg velük, hogy ha nagyobb hangsúlyt fektetnek a kommunikáció minőségére, és aktívan figyelnek egymásra akkor újabb veszteségeket tárhatnak fel a saját értékláncukban, és mint szervezet hatékonyabban működhetnek (ilyen veszteség például a kommunikáció minőségéből fakadó félreértés, ami után félremegy a fejlesztés, ami pedig csak tesztelési fázisban derül ki, és így tovább).
Példa #2:
Ha egy ilyen csapatban mégis megragadja valami új a figyelmet, például Velocityt akarnak mérni, akkor meséljünk bátran nekik a Velocity fogalmáról, mérési módszereiről, lehetőleg jó sok más üzletágból származó tapasztalattal együtt. Imádni fogják! Az emberi agy úgy van drótozva hogy a sztorit, a narratívát jegyzi meg, nem egy ppt-n felsorolt bullet pointokat. Már az őseink is inkább meséltek a tűz körül, slide-ok megosztása helyett…
Mielőtt elindulnál:
Gondold át, mit vársz és mit várhatsz az adott projekttől, a csapattól, a céges kultúrától és főleg önmagadtól. És ami még fontosabb, járj nyitott szemmel! Ismerd fel azt, mikor kell keményen beléjük állni, illetve mikor válsz sokká, és kellene inkább félreállni és hagyni, hogy a saját útjukat járják.
Az Agile legnagyobb ellensége nem a Waterfall, hanem a Bad Agile. Vagy ahogy Simon Sinek mondaná: „Sometimes you are the problem”
