Szerző: Novák István
Kinek jut eszébe csapdát állítani?
Viccesen hangzik, hogy valaki szándékosan csapdát állít egy agilis fejlesztőcsapat útjába, ahogyan az a jó- és rosszfiúkat felvonultató amerikai akciófilmekben történik. A szomorú helyzet az, hogy ilyet szándékosan nyilván senki nem tesz, de tudatlanul mégis. Az elmúlt években több ügyfelemnél is találkoztam az itt leírt tipikus helyzetekkel. Ennek a bejegyzésnek az a célja, hogy még te is időben felismerhesd és elkerülhesd ezeket.
Ahogyan a mondás is említi, “a pokolba vezető út jószándékkal van kikövezve”. Na de hogyan is vezethet ez a jószándék a túszejtésig?
“Ennek a sztorinak csak így van értelme”
Ha szeretnéd elérni, hogy jó képességű fejlesztőid rengeteg időt pazaroljanak el egy termékképesség fejlesztésére, győzd meg arról őket, hogy az általad felvázolt eposzok valójában sztorik. Nincs értelme, hogy azokat kisebb darabokra bontsátok a megvalósítás során, mert külön-külön nem biztosítanak értékes, az ügyfélnek eladható eredményt. (Ha nem volnál teljesen otthon az agilis terminológiában: a sztori kis méretű, jól definiálható, a szükséges ráfordítások szempontjából jól megbecsülhető és tesztelhető munkadarab; az eposz pedig olyan “specifikációszerűség”, amelyet a hatékony megvalósításához még átgondolt módon sztorikra kell bontani.)
Azok a fejlesztőcsapatok, amelyek még nem rendelkeznek több éves agilis fejlesztési tapasztalattal, hajlamosak a felülről jövő főnöki szó vagy akarat elvárásának megfelelni. Ha fel is ismerik, hogy egy sztoriként tálalt történet valójában eposz, gyenge kísérleteket tesznek arra, hogy erről a sztori gazdáját (legyél az te, a termékgazda, azaz a Scrum terminológia szerint product owner, vagy egy üzleti elemző) meggyőzzék, de ellenállásuk hamar megtörik. Az is előfordulhat, hogy nagyon jól látják ezt a helyzetet, és a “mindenképpen bontsuk le ezt a masszát kisebb gombócokra” viselkedésüket a “felsőbb akarat” makacskodásnak minősíti, és végül minden marad az eredeti elképzelések szerint.
Ha az eposzok közvetlen megvalósítására ereszted rá a fejlesztőcsapatot (azok mellett, hogy valószínűleg már a motivációjuk sem 100%-os), komoly gondban lesznek a feladat méretének megbecslésével. Akár alá (és ez a gyakoribb), akár fölé becslik a szükséges ráfordításokat, valamit mindenképpen veszítesz. Az első esetben a késlekedés, csúszás teremt rossz hangulatot, a második esetben pedig a feladat ki fogja tölteni a rendelkezésre álló időt. Az igazi veszteséget az fogja jelenteni, hogy a bizonytalan, teljes egészében át nem látott, ki nem fejtett sztorik rengeteg előre nem látható extra munkát állítanak a fejlesztőcsapat elé. Nagyon sok olyan tevékenységet fognak elvégezni és olyan részeredményeket produkálni, amelyek végül nem fognak bekerülni a termékképességbe, vagy nem úgy kerülnek be, ahogyan azok eredetileg elkészültek.
“Ha már úgyis itt jártok…”
“… ez az apró módosítást is csináljátok meg!” A fejlesztőcsapatokat ragyogóan kibillentheted egyensúlyukból egy ilyen feladattal a sprint során! A csapat a sprint indítása előtt vállalást tett, vagyis nevesítette azokat a sztorikat (és egyéb backlog bejegyzéseket), amelyeket majd a sprint során az elvárt (és ellenőrizhető) minőségben megvalósít. Egy ilyen egyszerű kéréssel nagy valószínűséggel újabb, korábban be nem vállalt terhet helyezel a vállukra. Attól, hogy te apróságnak látod a módosítást, az még sok emberórát leköthet, de arra mindenképpen alkalmas lehet, hogy legalább egy kicsit elvonja a csapat figyelmét a fontos feladatokról.
Az egyik tipikus esetem az az ügyfélem, aki egy apró módosítás gyanánt csak egyetlen kijelölőmező (checkbox) elhelyezésére kérte meg a fejlesztőcsapatot, a csapat pedig önszántából és vidáman sétált bele a csapdába: “ne vitatkozzuk, gyorsan feltesszük a képernyőre, ez hamar megvan”. Két nappal később (alig három nappal a sprint vége előtt) kiderült, hogy “ja, nem elég csak ennek a mezőnek az állapotát elmenteni, hanem ha ki van jelölve, még azt is ellenőrizni kell, hogy…”. A három pont helyén egy izmos, a triviálistól távol álló üzleti szabály megvalósítása szerepelt.
Ha menet közben újabb feladatokat próbálsz rányomni a fejlesztőcsapatra (amellett, hogy bizonyára romlik a motivációjuk), akár az egész sprintet is veszélybe sodorhatod. Nagyon gyakran egyszerűnek látszódó feladatok sokkal bonyolultabbak, mint hinnéd, de legalább egy közös, alapos átgondolást igényelnek, amelyben te és a projektcsapat közösen végeztek. Ezek az “apróságok” megbonthatják a csapat napi munkáját, feladatváltosokra késztethetik őket, és a bizonytalanság nyilvánvalóan frusztrálja is őket.
“Géza, volna itt egy sürgős dolog!”
Mutasd meg a csapatnak, milyen jól elviselik ha hirtelen kirántasz alóluk egy csapattagot, akinek fontos feladatot adsz: például ajánlatot kell írnia, vagy be kell mennie egy hosszú megbeszélésre. Ha igazán hatékony akarsz lenni, akkor ezt egy sprinten több alkalommal is eljátszod. Ezzel sikeresen állítod őket valódi kihívások elé. A sprintet a csapat nyilvánvalóan egy adott erőforrás-kapacitással tervezte, és te most ezt a rendelkezésre álló kapacitást csökkented azzal, hogy más feladatokra csoportosítasz át embereket. Nyilvánvalóan ilyen az élet, mindig új üzleti kihívások és helyzetek jönnek, amelyekre reagálni kell. Semmi probléma, hiszen több ragyogó lehetőség is van a kapacitás növelésére. Lehet a munkaidőn túl vagy akár hétvégén is dolgozni!
Az ilyen előre nem tervezett dolgokat nem szeretik a fejlesztőcsapatok, mert töréseket jelent az eltervezett munkában, és értelemszerűen az erőforrások újbóli elosztása, átcsoportosítása is extra ráfordításokkal jár. Nyilvánvalóan a túlóra sem a csapattagok álma.
Ha az ilyen váratlan feladatokat nem megfelelően kezeled, a fejlesztőcsapat frusztráltsága mellett komolyan veszélyezteted a sprintet és a terméket. Valószínűleg ilyen körülmények között a “kirántott” csapattagok az extra feladataikat sem feltétlenül azon a motivációs szinten végzik, mint amit te feltételezel.
Most akkor ki a túsz?
Egy ilyen helyzetben a fejlesztőcsapat tússzá válik: bár önjáróan kellene dolgoznia, a fenti viselkedéseddel ezt az önállóságukat, szabadságukat veszélyezteted. Minél gyakrabban állítasz ilyen csapdákat, annál inkább tússzá válik. Sőt a végén már természetesnek veszi ezt a helyzetet, és a “Stockholm-szindróma” mintájára már segít is neked az ilyen helyzetek kialakításában. Lehet, hogy nem ismered fel, de gyakorlatilag a csapattal együtt a fejlesztés alatt álló termék is és te is túsz leszel. Végeredményben a saját cégedet, szervezeti egységedet ejted foglyul.
Szedd fel a csapdákat!
Sőt, el se helyezd őket! Néhány egyszerű (legalább is annak tűnő) alapvető elv betartsával elkerülheted ezeket a helyzeteket!
- Helyezz hangsúlyt az előkészítésre! Ha az eposzokat értelmesen kezelhető sztorikra bontod (“osszd meg és uralkodj”), a komplex problémákat egyszerűbben kezelhető és kommunikálható részekre bonthatod. Ez jobban segíti azt, hogy a fejlesztőcsapat megérthesse a termékbővítményt, és hatékonyabban dolgozhasson annak megvalósításán.
- Bízz a csapatban, és kíméld meg őket a váratlan feladatoktól! A kiszámíthatóság, a nyugodt környezet erősíti és hatékonyabbá teszi a csapatot.
- Valamit-valamiért. Az életben természetesen vannak váratlan helyzetek, ezt minden fejlesztőcsapat tudja. Ha a váratlanságnak mindig az a kimenete, hogy a csapat újabb terhet kap a nyakába, motivációjuk drasztikusan romlik. Próbáld meg ezeket az extra terheket csökkenteni, minél rövidebbé tenni az ilyen “átmeneti állapotot”, és gesztusokkal kifejezni a csapat felé, hogy értékeled erőfeszítéseiket. Senki nem tiltja meg neked, hogy egy hosszabbra sikeredett nap végén pizzát rendelj nekik…
Természetesen sokkal könnyebb ezeket a nagyszerű tanácsokat csak leírni, mint működővé tenni. Olvasd ezt a blogot, ahol rendszeresen jelentkezünk hasznos technikákat bemutató cikkekkel!