carryover

9 tanács a sikeres sprinthez

A legtöbb agilis csapat iterációkban – ún. sprintekben – dolgozik, melynek hossza csapatonként eltérő lehet – a legtöbb csapatnál két hét hosszú, de nem ritka az egy, három- vagy négyhetes intervallum sem. Ezidő alatt megpróbálják elvégezni az összes betervezett feladatot, mely többnyire egy product backlog bizonyos részét jelenti.

A csapattagok a saját képességeiket, a hasonló fejlesztésekben szerzett tapasztalataikat és a követelményeket figyelembe véve igyekeznek minél pontosabb becslést adni az egyes backlog elemekre. Minél pontosabbak ezek a becslések, annál pontosabban meg tudják jósolni, mit is képesek leszállítani az adott sprint végére – tehát, hogy mekkora a kapacitásuk.

A csapat ezután mindent bevetve dolgozik azon, hogy ezeket a fejlesztéseket le is szállítsa, de csak a sprint végéhez közeledve derül ki, hogy mi is készül el ezekből valójában.

A legjobb törekvések ellenére is előfordul, hogy a tervezettek közül nem sikerül mindent leszállítani, ezek a backlog elemek pedig gyakran átkerülnek a következő sprintbe.

Ez több okból is probléma.

Ha félig kész munkák lógnak körülöttünk a levegőben, akkor egyre nehezebb lezárni őket és egyre kevésbé érzzük az önbizalmat, hogy bármikor készen állunk egy telepítésre – a telepített kód stabilitásáról nem is beszélve.

Mindannyian szeretünk a végére érni annak a munkának, amibe belekezdünk – ha ez mégsem sikerül, az frusztrációt okoz. Ez azonban nem csak nekünk jelenthet csalódást, de azoknak a stakeholdereknek is, akiknek a fejlesztéseket szállítjuk.

A csapat morálja csökken, az elmaradozó user story-k pedig könnyen szokássá válnak. Egy idő után azt vesszük észre, hogy úgy tervezünk be 30 story pointot egy sprintre, hogy előre tudjuk: valószínűleg csak 20-at fogunk tudni leszállítani belőle.

Ez nem is túl inspiráló és nem is igazán élvezzük, de a minőség szempontjából is problémákat vet fel. Ha félig kész munkák lógnak körülöttünk a levegőben, akkor egyre nehezebb lezárni őket és egyre kevésbé érzzük az önbizalmat, hogy bármikor készen állunk egy telepítésre – a telepített kód stabilitásáról nem is beszélve.

Ezek a félig kész munkák idővel technikai adósságokhoz vezetnek, azok support ügyeket okoznak, ettől máris sokkal nehezebben köteleződünk el a sprint scope mellett, mert a support idővel és az élesből visszaeső bugokkal nem tudunk előre számolni, az egész pedig lassan egy végtelen körforgássá válik.

Vannak csapatok, akik kitalálják, hogy ebben a helyzetben csak a hosszabb sprint jelenthet megoldást: ha két hétbe nem férnek bele a munkákkal, akkor három hétbe biztosan bele fognak. Egészen logikusan is hangzik, de a valóságban ilyenkor a legtöbb csapat még több munkát vállal magára és rövidesen pontosan ugyanazzal a problémával szembesül, mint előtte. Ezt a jelenséget Parkinson törvényének hívják, amely kimondja, hogy “egy munka mindig annyira terjed ki, hogy kitöltse az elvégzésére felhasználható időt”. Ha a munkák befejezése nem válik szokássá, úgy három hét alatt sem fogjuk elvégezni a feladatokat, ezzel pedig csökken az agilitásunk, csökken a képességünk, hogy minél gyorsabban szállítsunk és hogy minél korábban kapjunk visszajelzést.

Ha olyan új, agilis környezetben dolgozunk, ahol még növelni szeretnénk a módszertanunkba vetett bizalmat, ott a sprint végén sorban álló elkészületlen munka nem segít sem ebben, sem az önbizalmunk növelésében. Ilyen helyzetben mind a csapatmorál, mind a kiszámíthatóság szempontjából sokkal jobb az a megközelítés, ha egy kisebb adag munkát biztosan szállítunk, szemben azzal, ha egy nagyobb adag munkát egyáltalán nem szállítunk le.

Bőven van okunk tehát arra, hogy miért is érdemes elkerülni a leftovert, de mit tehetünk ezért egyéni és csapat szinten?

Egyik fejlesztő tanítja a másikat

Rövidítsétek le a sprintet

Ugyan éppen most veséztük ki a hosszabb sprintek hátrányait, ennek ellentéte mégis javulást hozhat.

Ha most éppen kéthetes sprintekben dolgoztok és nehézséget jelent ennyi idő alatt mindent elvégezni, akkor kipróbálhatjátok az egyhetes sprinteket.

Az egyhetes sprintek először kihívást jelenthetnek, de a mögöttes eszme a következő: ha kevesebb dolog fér be a sprintbe, akkor a Product Owner segítségével a csapat kénytelen a feature-ket és user story-kat kisebb darabokra szeletelni. Ha kevesebb időbe kell beleférni, akkor a kisebb feladatokra pontosabb becslést tudunk adni, a kisebb feladatokkal könnyebben tudunk végezni, könnyebben köteleződünk el a scope mellett és kisebb egységekben, gyakrabban szállíthatunk.

Ennél a pontnál azonban érdemes vigyázni – bizonyos csapatoknál több időre lehet szükség pár napnál, hogy igazán belelendüljenek a munkába és azzal is érdemes számolni, hogy bár a különböző ceremóniák is rövidülhetnek valamelyest, de arányaiban több időt emésztenek így fel a sprintből.

Vegyétek az előző sprint eredményét

Annak a becslésére, hogy mekkora is lesz a csapat kapacitása a következő sprintben, legjobb azt megnézni, hogy mennyi munkát sikerült elvégezni ebben a sprintben. Ha most csak a munka 90%-ával sikerült végeznetek ahhoz képest, amit a csapat előzetesen megbecsült, akkor a következő sprintben csak ehhez a 90%-nyi kapacitáshoz tervezzétek be a feladatokat.

Ez elég logikusnak hangzik, de a valóságban a csapatok kitartóan szeretik győzködni magukat, hogy a következő sprint már más lesz és ezúttal jobbak lesznek a becslések is.

Ez idővel remélhetőleg így is fog történni, ám addig is használjátok azt az adatot, ami már a rendelkezésetekre áll.

Érezzétek rosszul magatokat

Bár ez tanács elsőre vitathatónak tűnhet, mégis minden csapatnak éreznie kell bizonyos mértékig egyfajta bűntudatot, ha nem sikerül leszállítania azt, amire előzetesen azt jósolta, hogy le fogja tudni.

Ez a bűntudat egy belülről jövő bűntudat kell legyen és nem feltétlenül mások miatt kell érezni – egy magatokkal szemben támasztott rossz érzés, hogy nem sikerült mindennel elkészülni.

Ez azért fontos, mert így működünk: ha valami miatt rosszul érezzük magunkat, akkor sokkal nagyobb a belső ösztönzés, a belső motiváció, hogy legközelebb tegyünk ellene valamit – kezdetnek elég lehet egy perc néma csend a Retrospective végén az összes olyan story-ért, amelyek elestek ebben a sprintben.

A lényeg, hogy szánjatok rá egy kis időt és energiát azáltal, hogy elgondolkodtok: ez így nem volt túl ideális, de legközelebb jobban csináljuk.

Csökkentsétek a Work in Progresst

A cél mindig az, hogy minél kevesebb dologra kelljen egyszerre fókuszálnia a csapatnak. Ha az elmúlt időszakban kb. nyolc backlog elemet volt szokás bevenni egy sprintbe, akkor a következő alkalommal a Planningen csak négy backlog elemet vegyetek fel a sprint backlogra.

Ezt a négy elemet remélhetőleg sikerül is elvégezni, ekkor pedig még maradhat is hátra plusz idő a sprintben. Ebben a maradék időben be lehet húzni a megmaradt négy backlog elemet, de talán ennél is jobb, ha a csapat innentől csak egyenként húzza be őket, mert ilyenkor sokkal könnyebb csak arra a feladatra fókuszálni.

Ha kevesebb dologra fókuszáltok, csökken a context-switch miatt keletkező veszteség, javul a csapat együttműködése és felerősödik a tudásmegosztás.

Csökkentsétek a Work in Progresst a különböző folyamatokban

A csapatnak nem csak arra kell figyelnie, hogy hány elemen dolgozik egyszerre egy sprintben, hanem arra is, hogy egyik fejlesztési fázis vagy készség se legyen túlterhelve. Ha a csapat vizualizálni tudja a fejlesztési folyamatot elejétől a végéig, akkor könnyen előtűnhetnek bizonyos bottleneckek a csapaton belül. Előfordulhat, hogy a sprintben foglalkozni kell némi dizájnnal, kutatásra van szükség, kicsit több lesz a frontend vagy backend fejlesztés, esetleg a tesztelés. A lényeg, hogy megbizonyosodjatok róla, hogy egyik munkafázis sincs túlterhelve, azáltal, hogy WIP limiteket határoztok meg és be is tartjátok őket.

Ha az látszik, hogy már két feladat is tesztelésre várakozik, akkor ne adjatok a sorhoz egy harmadikat addig, amíg legalább az egyik nem készül el. Előfordulhat, hogy ehhez a swarming módszerét alkalmazva többen váltanotok kell ezekre a feladatokra, de a szabály egyszerű: minél hátrébb van egy feladat a fejlesztési folyamatban, annál inkább az a prioritás, hiszen abban van már a legtöbb energiánk.

Az egyik leggyakoribb hiba, amit egy agilis csapat tagjai az önszerveződés korai szakaszában elkövethetnek, ha arra koncentrálnak, hogy egyéni szinten minél több és több feladatot elvégezzenek, ahelyett, hogy csapatszinten tennék ugyanezt.

Ünnepeljétek meg, ha valami elkészült

Képzeljétek el azt a felemelő érzést, amikor végre kihúzhattok egy elemet a to-do listátokról. Ezt az érzést a csapatban is érdemes minél jobban megerősíteni – mondjuk egy gongütéssel megünnepelni minden egyes kitelepített user story-t. Persze egy ilyen kisebb szeánsz először furcsának tűnhet, de a lényeg, hogy hangsúlyozzátok ki az elvégzett feladat iránti pozitív érzést, mert akkor idővel sokkal inkább ezt akarjátok majd érezni és nem az fejlesztési oszlopokban felgyülemlő feladatok miatti frusztrációt.

Nem véletlenül ez az első kérdés a Daily Scrumon: mit fejeztünk be a legutóbbi alkalom óta? Ennek a kérdésnek pont az a célja, hogy meglegyen a haladás, a lendület, az “igen, elvégeztünk valamit!” érzése. Ha valami elkészült, akkor nyugodtan nézzetek körül, gratuláljatok a másiknak, értékeljétek és ismerjétek el az ő és az egész csapat munkáját.

Csapat ünnepli a feladat elkészülését

Védjétek a csapatot a zavaró tényezőktől

Egy másik gyakori oka annak, hogy csapatok nem tudnak minden feladatot elvégezni a sprintben az, hogy történik valami, ami eltereli a figyelmüket a vállalásukról. A fókusz ilyenkor elveszik, legyenek azok újonnan beérkező követelmények vagy zavaró tényezők a konkrét fizikai környezetükben.

A cél, hogy a csapat a ScrumMaster segítségével megvédje önmagát ezektől a zavaró tényezőktől és tisztázza mindenki felé, hogy az, amin ők dolgoznak nagyon fontos, és az az elsődleges feladatuk, hogy a vállalt feladataikat elvégezzék.

Ha elkerülhetetlen, hogy valakinek a csapatból eltereljék a figyelmét a nem tervezett dolgok, akkor a cél az legyen, hogy ez minél kevesebb csapattagot, lehetőleg csak egyet érintsen. Minél több ember foglalkozik minél több feladattal, annál nagyobb az ebből adódó veszteség. Mindig jelöljetek ki valakit, aki a beérkező kérdéseket megválaszolja, a support ügyeket megoldja, az ad-hoc megbeszéléseken a csapatot képviseli – a többiek pedig hadd dolgozzanak a sprint feladatain.

Ne mutassátok be a félkész munkákat

Amilyen tudatosan érdemes elismerni az elkészült munkát, ugyanolyan fontos, hogy ne engedjetek a kísértésnek és ne ismerjétek el partial creditként a csak félig elkészült munkát.

Talán túl nyersen hangzik, de ha valami nincs kész, akkor haszna sincs a végfelhasználó számára. Ne használjátok ösztönzésképp az el nem készült munkát és ne ismerjétek el teljesítményként – ha nincs kész, ne vigyétek a Sprint Review-ra és ne kérjetek érte elismerést.

Hozzátok be a tapasztalataitokat a munkába

Az egyik leghasznosabb dolog amit tehettek, ha egyenként végigmentek minden csapattagon és felteszitek a kérdést: mi az, ami működött már neki a múltban, ha a végére akart érni a feladatainak?

Ez nem kell, hogy közvetlenül a munkához kapcsolódjon: lehet akármi, munkán kívüli teendők, a házimunka vagy egy hobbi. A lényeg a szokások, amiket azért csináltok, hogy elkészüljetek a dolgaitokkal és az, hogy ezt a tudást és tapasztalatot áthozzátok a munkahelyi körülmények közé.

Van olyan, aki adoptálni tudott egy olyan produktivitási módszert, mint a GTD, valaki egyszerű listákat szeret vezetni, más a naptárába eseményként vezeti fel minden teendőjét, előfordul olyan, aki naplót vezet, hogy kiírja magából a gondolatait és van, aki szereti megjutalmazni magát valamivel minden elvégzett feladat után. A cél, hogy egyéni szinten ezeket a módszereket mindenki a munkahelyi körülményekre tudja szabni és azáltal, hogy az ezzel kapcsolatos kudarcokat és sikereket megosztjátok egymással, inspirációval és értékes leckékkel tudtok szolgálni a többi csapattag számára.

Mindenkit más módszer vezet el oda, amikor végre elégedett lesz a produktivitásával – ha valaki elégedett lesz az elvégzett munkájának mennyiségével és minőségével a munkájában, akkor többször érzi az elégedettséget is és ez a csapat hasznára válik.

Meg lehet próbálni ráerőltetni valakire azt, hogy befejezze a feladatait, de egészen más lesz az eredmény, ha sikerül ráébreszteni őt, hogy mennyire is szeretné ő elérni ugyanezt.