Az aktuális projektem közepe felé (5-7. sprint) a mérőszámok alapján már láttuk, hogy nem fogunk odaérni az aktuális velocityvel, ahova terveztük, időben. A csapat egy része számára ez nagy teher volt, a másik fele próbálta behozni, de csak kudarc lett belőle a sprintek végére. Az egész csapat stresszben volt, velem együtt,
a demot nem ünnepnek éltük meg, a hétvégék is ennek a rossz érzésnek a hatalmába kerültek. Mit tehet ilyenkor egy PO vagy a csapat?
A becslések nem voltak mindig pontosak, és a 2 hetes sprint nem adott elegendő kontrollt., tehát nem tudtunk időben beavatkozni, hogy sikeres legyen a sprint. A csapat mindig úgy látta, érezte, hogy a sprint végére össze fognak érni a szálak, be fogják hozni a storykat, de valahogy sosem sikerült. Egy-két story kihagyása végülis nem a világvége, de a sprintek számának növekedésével a le nem hozott storyk összege is emelkedett.
A másik probléma, hogy görcsösen ragaszkodtunk minden story elkezdéséhez. Így ha például 12 story volt betervezve a sprintbe, akkor a végén lett 10 darab 90%-ban kész story és két darab el sem kezdett story. De ha arra koncentráltunk volna inkább, hogy befejezett storykat hozzunk le, akkor lett volna 9 darab 100%-osan befejezett story, ami az ügyfél számára is nagyobb értékkel bír, mint több, de itt-ott sántikáló funkció.
Fontos volt valami akció tervet hozni, különben nagy baj lesz a végén. Két eszközt használtunk a sprint közbeni ellenőrzésre.
Meghatároztunk sprint közbenre egy milestone-t, ami a planningen definiált, és az előzetes becslés alapján addigra lehozható storykat tartalmazta. Ezeknek a storyknak a milestone-ra el kell készülnie, ha más külső akadályozó tényező nincsen.
A másik módosítás a feature freeze volt, ami arra irányult, hogy a sprint forduló előtt 1 nappal nincs több új task fejlesztés, hanem a meglévő bugok javítása, az addig elkészült storyk jobbítása volt a cél. Mivel a tesztelő 1 nappal a sprint forduló előtt kapja meg az összes storyt (vegyük figyelembe, hogy jelen esteben komoly függések voltak a storyk között), így kevés idő maradt a funkciók összefüggésében való tesztelésére és a feltárt hibák javítására, sajnos sokszor előfordult, hogy a demo előtt 10 percel még volt merge request.
A milestone beiktatása technikailag annyit jelentett, hogy kedd délután már csak bug javítás volt, új task fejlesztése nem, és szerda reggel tartott egy mini demot a tesztelő nekem.
Ugyan a milestone felfogható pótcselekvésnek a burndown chart helyett, de amíg nem működik jól egy csapat, addig nem ez nem ad pontos visszajelzést, és segít a csapatbak fokúszálni arra, hogy hol tratanak és valóban oda tudunk-e érni a sprint végére, a projekt végére.
A bevezetett intézkedések több kontrollt adtak a kezünkben és az elmúlt 3 sprint tapasztalata alapján elmondható, hogy pozitív hatással volt a csapat teljesítményére, az ügyfélnek szállított értékre.
És hogy ez mennyire agilis? Miért nem álltunk át inkább 1 hetes sprintekre?
A csapat félt attól, hogy a plusz agilis események annyi időt vesznek el, amit jelen szituációban a csapat nem vállalt be.
Mindenképpen szerencsésebb az a fajta hozzáállás, hogy kevesebb, de teljesen jól működő storykat hozzunk le egy sprintben, mint folyamatosan magunk előtt görgetünk minden storyt sprintről-sprintre.
