Minden ügyfélnél előfordul hogy a fejlesztőcsapata olyat vállal, amit nem tud teljesíteni. Szervezet és porjektmérettől függetlenül. Ilyenkor többnyire mindenki hibás és egyben senki sem.
Amikor a szoftverfejlesztési projekt megcsúszik, és ez klasszikus közegben a norma (még csak nyomokban sem Agile), a menedzsment automatikusan nyomásgyakorlással akarja behozni a lemaradást. Igen ám, csakhogy a szoftverfejlesztés nem egy termelési történet ahol lehet “feszíteni a gépeket”.
A szoftverfejlesztők tudásalapú gazdaságban próbálnak eredményeket létrehozni, és mint ilyen, erősen ki vannak téve annak a változékony állapotnak amikor vagy van ihlet vagy nincs, vagy van biztos tudás vagy nincs. Sokszor kutatni kell a megoldáshoz.
Könnyen előfordul, hogy rutintalanság miatt nem a legjobb megoldásokat választjuk, ami viszont azzal jár hogy újra kell írni kódrészeket, a kódreview hosszadalmasabb lesz (ha egyáltalán van!), vagy olyan technológiai adósságot halmozunk fel a döntéseinkkel, ami miatt a szoftver fenntarthatósága sérül.
Egyszóval a tudás alapú gazdaságban való működés nagyon ki van téve annak a szeszélyes és változékony erőtérnek amit úgy hívnak, hogy emberi tudás, intuíció, ihlet és rutin.
Nyomás
Ha egy szoftverfejlesztő csapatra a menedzsment nyomást helyez, mert látja vagy érzi, hogy elmaradnak a tervezett haladástól, annak természetes következménye, hogy a csapat átvált védekező üzemmódba, és meg fogja ígérni mindent, amiről úgy gondolja, hogy elvárnak tőle.
Nyilvánvaló hogy ennek az ígéretnek nincs valós alapja, de ez az Agile-t nem ismerő menedzsmentet a legkevésbé sem zavarja. Nem kérdezi, hogy mire alapozza bárki is, a kétszer akkora vállalást, amikor a korábbit sem tudta szállítani.
Riportok márpedig vannak! Csak túl nagy időtávokban, túl nagy lépésekben ahhoz, hogy kiváló vezetői döntéseket lehessen hozni, amikor és ahol ezekre a döntésekre a legnagyobb szükség van.
Csúszás esetén, nyomás alatt a csapat megígéri, hogy “… Hajj! Most kétszer annyit fogunk behozni, mint előzőleg!…” Meg is próbálják, túlórázni fognak, hétvégén is dolgoznak. Az egyetlen dolog, amit nem kezelt senki ebben a helyzetben az a “tudás, rutin, intuíció, ihlet” alkotta változékony erőtér.
Így biztos hogy még több hibát fognak véteni és még kevesebbet fognak tudni szállítani. Törvényszerűen még annyit se, mint amikor nem ígértek ennyit.
A menedzsment boldogan megy dolgára az egyre megalapozatlanabb ígéretekkel. Csakhogy ezek az ígéretek valójában kikényszerített ígéretek. Egyetlen, ki nem mondott célja az, hogy a non-menedzsment kollégákat, a későbbiekben hibáztatható pozícióba kergesse. Gonosz dolog, még ha olykor nem is tudatos játék eredménye. Túl sokszor láttam azonban, hogy ez szándékos taktikázás a menedzsment részéről.
Csodák márpedig nincsenek
A menedzsment az ígéretekkel megelégedve várja, hogy majd az új határidőre találkozni fog a csodával, és a csapat valóban kétszer annyit szállít.
A csoda természetesen nem történik meg.
Valójában megint elment egy rakás idő és a két “mérföldkő” között nem kapott senki használható, azaz döntésre alkalmas, visszajelzéseket. Kommunikáció van bőven. Pl.: “Béla már belebetegedett a túlórába”; “Gézát meg otthagyta a csaja”; “Ildikónak meg kiújult a lumbágója a stressztől”.
A stressz és a kiégés jelenségével a felszínes kommunikáció szintjén túl valójában nem foglalkozik a menedzsment. A lényeg, hogy a még nagyobb az elmaradást még több erőfeszítéssel, de be kell hozni! Ezzel az ördögi kör be is zárult, és a csapat és a projekt fénysebességgel elindul a totális bukás felé.
A feloldozás
Van rá megoldás.
Ne kérjünk ígéretet a csapattól soha semmire… megalapozatlanul! Nem érdekel, hogy mit gondol a csapat, hogy mit szeretnének! Nem érdekel, hogy ki tudják-e találni a titkos gondolataimat és vágyaimat! Nem érdekel, hogy milyen ígéretekkel próbálnak meg elkápráztatni, mert úgysem nem hiszem el!
Mit lehet akkor csinálni?
Ha a csapat már megtanult nem-ígérgetni, megtanulhat helyette commitmentet tenni.
A commitment és az ígéret között a különbséget így szemléltetném: “Drágám elviszlek este vacsorázni!” Ez egy commitment. Ha ezt a commitmentet az ember megszegi, akkor jogosan húzta magára a haragot.
Az hogy ez a vacsora a sarki gyros-osnál lesz, vagy egy elegáns étteremben, arról senki nem beszélt. Ez utóbbi az ígéret. Ha lemegyünk a sarki gyros-oshoz és vacsoráztunk, a commitment teljesült. Az elvárásoknak megfelelően? Ki beszélt itt bármiféle elvárásról?
Hagyjuk abba az ígérget(tet)ést és álljunk át a commitmentek gyakorlatára.
Commitment kultúra bevezetése
Első körben a csapat környékén kell a transzparens működést elkezdeni, hogy lássuk mennyi a csapat de facto teljesítménye egy adott időintervallumban. Egy hetes intervallumokban érdemes gondolkodni.
Ahhoz hogy a commitment gyakorlatát elkezdhessük, először is jól definiált feladatok kellenek.
Az esetek 99 %-ában azok a csapatok, akik a menedzsment szerint csak ígérgetnek és soha nem szállítanak időben, legtöbbször nem rendelkeznek jól definiált feladatokkal, csak azok illúziójával.
Nem kapnak kellő mennyiségű időt, hogy kezeljék az igények bizonytalanságait, kockázatait, érdemi válaszokat kapjanak a kérdéseikre. Ha a menedzsment a csapatot magára hagyja, mondván, hogy “megkapták a specifikációt, bontsák le!”, biztos a projektbukás.
Az eddigi tapasztalataim mind azt mutatták, hogy a menedzsment / üzleti döntéshozók elfoglaltsága a fő oka annak, hogy egy csapat nem képes jól definiált feladatokkal (üzleti igényekkel) dolgozni.
Mint ilyen, commitmentet sem tudnak tenni. Nincs mire. Maradnak viszont az alaptalan ígéretek. Nem a csapat felelőtlensége, hanem a menedzsment / üzleti döntéshozók hibás működése miatt.
A jól definiált feladat
Egy feladat akkor van jól definiálva, ha bármilyen ország fejlesztője, bármilyen körülmények között a feladatot elolvasva tudja, hogy mit kell csinálnia. Kód szinten. Ez igen nehézkes és drága folyamat. Épp ezért nem is csinálunk belőle többet, mint amennyire éppen feltétlenül szükségünk van a következő legrövidebb fejlesztési időintervallumban.
Ha megtanultunk jól definiált feladatokat írni, és megtanultunk a jól definiált feladatokról teljesen semleges és professzionális módon és környezetben beszélni egymással, akkor már van esélyünk arra, hogy commitmentet tegyünk a korábbi tényleges mért teljesítményeink alapján.
Ha nincsenek ilyen előzetes mérési eredményeink, akkor egy héten keresztül nézzük meg, hogy jól definiált feladatokból a csapat hány darabot tudott megcsinálni a héten. Darab-darab, egy ideig nem lesz ennél többre szükségem.
Ha tudom, hogy egy csapat jól definiált fejlesztési feladatokból mondjuk megcsinált nyolcat egy héten, akkor azt is tudom hogy 8-10 jól definiált feladatnál többre valószínűleg nem lesz szükségem a következő héten sem. Tehát ennyit kell előre előállítanom.Ha ez sikerült, és az látszik, hogy kifogyunk a feladatokból a hét vége előtt, hát tervezünk és írunk még! Na és?!
Soha nem töltünk el jelentősen több időt, sem kevesebbet azzal, hogy feladatokat definiáljunk a csapattal közösen. Innen már kiszámítható lesz, hogy várhatóan mikor és mennyi erőforrást kell félretennem feladatok helyes definiálására, a menedzsment, üzleti döntéshozók és a csapat részéről egyaránt. A szereplők körét nem szűkíthetem! Ezt az erőfeszítést nem spórolhatom meg!
Keep calm, and keep progress!
A csapatnak az elmúlt héten 8 db jól definiált feladatot sikerült szállítania, ennél többet a következő héten se várjunk el!
És ha felteszik a kérdést, hogy “mi van ha mondjuk csak hatot tudunk megcsinálni a következő héten? Mert ezek a jól definiált feladatok nagyobbak és munka intenzitás szempontjából igényesebbek, mint az előző héten voltak” az sem baj! Akkor tudjuk előre, hogy erre a hétre 6 db lesz. Ez viszont commitment! Ez nem ígéret.
Ahhoz, hogy a commitment a legnagyobb valószínűséggel elkészüljön, mentesíteni kell a csapatot, hogy bármi mással foglalkozzanak, mint a jól definiált feladatokkal.
A csapat akkor nyúlhat bármi máshoz, ha:
- A commitmentet korábban befejeztétek és egyeztettünk arról, hogy mi lesz a következő feladat,
- Olyan információ birtokába jutottatok ami miatt muszáj változtatni a megbeszélteken. Természetesen ez esetben is kötelező egyeztetni a menedzsmenttel és üzleti döntéshozókkal. Méghozzá közvetlenül és azonnal!
Bármilyen feladatról is legyen szó, mielőtt elkezdheti a csapat, jól definiált feladatokra kell bontani. Válságmenedzsment helyzetben sem spórolhatjuk meg ezt a lépést!
A valós teljesítmény
Három négy olyan hét után, amikor jól definiált feladatokkal dolgoztunk és helyesen mértünk, a csapatok többnyire megtalálják a saját valós teljesítményüknek az átlagát.
Könnyen lehet, hogy ez a sebesség nem lesz elég ahhoz, hogy a projekt elkészüljön határidőre. Ez alapvetően egy menedzsment oldali hiba. Lehet hogy készült egy 800 oldalas specifikáció, de 800 oldalt nem lehet jól definiált feladat szinten (gazdaságosan!) letervezni. És az is biztos, hogy tele van lyukakkal és logikai inkonzisztenciával.
Az ilyen projektet biztos, hogy rosszul indítjuk el:
- Nem megfelelően mértük fel a kockázatokat
- Hibásan azonosítottuk a projekt teljesítéséhez szükséges tudásbázist
- Nem megfelelő mennyiségű és tudású embert válogatunk a csapatba
- A csapatnak nincs, nem lehetett, valós teljesítmény monitorozása
Lásd “Miért jobb a backlog, mint a specifikáció” blogbejegyzésünk. http://hu.nitrowise.com/miert-jobb-a-backlog-mint-a-specifikacio/
Ha kevés, ami lenni tud
Ha a csapat sikeresen eljutott odáig, hogy a saját teljesítményével már legalább egy hét távlatában tisztában van, és a menedzsment úgy gondolja, hogy ez így kevés lesz az üdvösséghez, akkor sincs semmi baj.
A relatív becsléses módszerének segítségével nézzük meg, hogy mennyire vétenénk el a célt.
Hagyjuk a csapatot a valós teljesítménye, commitment mentén szállítani, legalább négy iteráción keresztül. Ezután nézzük meg, hogy az ebben az időszakban letett előrehaladás hogyan viszonyul a még előttünk levő feladatok várható nagyságához és bonyolultságához.
Relatív olcsón meg tudjuk ítélni, hogy a vizsgált időszakhoz képest, hányszor lesz nehezebb, vagy könnyebb ami még biztosan ránk vár, és melyek azok az elemek, amiket további elemzés nélkül meg sem tudjuk ítélni.
Amit meg tudtunk ítélni, azt egyszerűen fel kell szorozni a mért időszak számaival. Ezzel a módszerrel nagyon olcsón, és nagyon hamar kapunk megalapozott képet a projekt várható alakulásáról.
A relatív becslési feladatot rendszeresen el kell végezni!
Commitmentet, csakúgy mint ígéreteket kikényszeríteni felesleges. Csak a projektet és a kollégáink egészségét veszélyeztetjük vele.
Commitmentet a csapat tud tenni, ha:
- Ismerik a saját lehetőségeiket és képességeiket
- A menedzsment ennek megismerésében támogatja őket
- Vannak olyan mérések, amik objektíven jelzik, ha túl akarják vállalni magukat, vagy alul vállalni magukat.
A behozhatatlan versenyelőny karnyújtásnyira van...
Az agilis módszertani átállás során a szervezetek egységnyi időre vetített termelő képessége átlagosan 150-300%-kal nőtt. A HVG Akadémia, Agile Recruiter sorozatának módszertani vezetője.