Velocity metrika je zaradi pogostih anti vzorcev, ki se pojavljajo v zvezi z njo, na precej slabem glasu. V pričujočem članku opisujem kakšna je vloga Velocity metrike v več timskem okolju, čemu ne služi in kako jo lahko proaktivno uporabimo za planiranje releasa v produkcijo.
Začnimo z enotami s katerimi merimo Velocity.
STORY POINTS
Predno, Agilni tim funkcionalnost ali uporabniško zgodbo prevzame v razvoj, jo oceni glede zahtevnosti/velikost. Enota za oceno je običajno Story Point, čeprav nekateri timi uporabljajo lastno izrazoslovje (Gummy Bears, NUTs …). Velocity
To ni samo Scrum praksa, ampak “sizing” izvajata tudi Kanban in Scrumban, čeprav promotorji teh frameworkov to radi zanikajo. Kanban tim, sizing običajno izvaja na Weekly Replenishment in Delivery Planning dogodkih, ko člani ocenjujejo verjetnost, da bo neki feature dokončan v npr. 10 dnevih. Scrumban pa pozna Trigger Planning, ki je dinamičen glede na hitrost razvoja in pravtako služi ocenjevanju zahtevnosti izvedbe backlog elementov.
Namen ocenjevanja je:
- Razgovor o funkcionalnostih in uporabniških zgodbah, kar vodi v njihovo boljše razumevanje, identifikacijo mogočih problemov, razkritje nefunkcionalnih (backend) zahtev in izločanje funkcionalnosti z nizko poslovno vrednostjo. V tem razgovoru so poleg razvojnikov ključni Product Owner in po potrebi predstavniki končnih uporabnikov, ki najbolje poznajo problematiko in pričakovano poslovno vrednost.
- Preverjanje ali je tim predlagano uporabniško zgodbo sposoben realizirati v naslednjem Sprintu in po potrebi njeno razbijanje na manjše pod zgodbe. To je pomembno, saj naj bi tim na koncu vsake iteracije predstavil produktni inkrement z neko poslovno vrednostjo. Ta inkrement je (idealno) tudi pripravljen za takojšnjo vključitev v produkcijo (Done). Pri Kanbanu je ta meja običajno večji release v produkcijo.
- Tim prevzame v razvoj toliko uporabniških zgodb kot je njegova kapaciteta (Velocity) glede na izkušnje preteklih iteracij. Idealno to ni ena sama velika uporabniška zgodba, saj tim na ta način tvega, da na koncu iteracije ne bo imel Done inkrementa. Če tim razvija več manjših zgodb, vsako s svojo poslovno vrednostjo, blokada ene zgodbe, verjetno ne bo ogrozila cilja iteracije (Sprint Goal), tim pa bo kljub temu generiral določeno poslovno vrednost. Tipična uporabniška zgodba naj bi predstavljala 2 do 3 dni dela enega razvojnika. Seveda pa je to odvisno od konteksta.
Story Point je manjša enota dela, ki jo poznajo vsi člani tima in se strinjajo o njeni velikosti. Velikost ostalih uporabniških zgodb se nato ocenjuje kot večkratnik “bazne” Story Point. Običajno pri tem uporabljamo faktorje Fibonaccijevega zaporedja (1, 2, 3, 5, 8, 13,…).
Primeri bazne (1) Story Point uporabniške zgodbe:
- Dodajanje login gumba na WEB stran
- Vsebina tabele na WEB strani prebrana s SQL strežnika
- Priprava darilnega paketa za povprečno pridnega otroka (Božičkova metrika)
- Inštalacija in konfiguracija SQL strežnika
- WEB stran s 50 samostojnimi tekstovnimi polji
- Pojesti eno čokoladno ploščico
- Prikaz GDPR pop-up na WEB strani
- API poizvedba in vpis preračunane vrednosti v polje
- …
Velikost Story Point je specifična za tim. Tekom razvoja naj se nebi spreminjala, saj nam to pokvari metrike. Velocity je število Story Points, ki jih je tim realiziral v eni iteraciji. V več timskem okolju ni potrebe po poenotenju bazne Story Point med timi. Edini možni razlog za to, bi bila želja po medsebojni primerjavi produktivnosti timov, kar pa je v popolnem nasprotju z Agilno filozofijo.
VELOCITY
V Scaled Agile, kjer več timov razvija skupni produktni inkrement, se nam glede različnih velikosti Story Points in s tem povezane Velocity postavi par vprašanj:
- Kako planirati, če ima vsak tim svojo lastno bazno Story Point?
Bazna (1) Story Point velikost, ki si jo izbere posamezni tim ne vpliva na planiranje. Tim prevzame v razvoj toliko uporabniških zgodb, kot je njegova dotedanja Velocity. Velikost uporabniške zgodbe tim oceni z lastnim merilom. Predpostavljamo, da imajo enako veliki timi, enako izkušenih razvojnikov približno enako kapaciteto. Neglede na to s koliko timskih Story Points je bila ocenjena določena uporabniška zgodba.
- Kako primerjamo produktivnost različnih timov?
Tega v scaled Agile okolju ne počnemo. Skupina timov, ki dela na istem produktu se ocenjuje in nagrajuje kot celota.
- Na čemu potem baziramo nagrajevanje timov?
Nagrajevanje temelji na principu “nivoja višje”. To pomeni, da se ne nagrajuje individualnih timov glede na njihovo produktivnost, ampak skupino timov kot celoto glede na ustvarjeno poslovno vrednost. Ta način nagrajevanja vzpodbuja med timsko sodelovanje in deljenje dobrih praks ter informacij, kar je navsezadnje cilj Scaled Agile praks.
- Ali lahko predvidimo datum releasa glede na to, da so Velocity timov neprimerljivi?
Da, metoda je opisana nižje v članku.
- Kako managementu poročati o produktivnosti timov?
Tega ne počnemo. Za poročanje, je metrika ustvarjena poslovna vrednost. Če poslovna vrednost z iteracijami pada, je to predvsem odgovornost produktnega managerja ali Product Ownerja in ne razvojnikov. Določen padec poslovne vrednosti skozi iteracije je pričakovan, saj timi vedno najprej razvijajo funkcionalnosti, ki imajo najvišjo poslovno vrednost/ROI. Ko se pomikamo nižje po backlogu, se vrednosti naravno nižajo. Razvoj novih funkcionalnosti je priporočljivo prekiniti, predno njihov ROI pade v negativo.
- Kakšen je vpliv AI na produktivnost v več timskem okolju?
Potencialni konflikt, ki nastane kot posledica različne uporabe AI je opisan v tem članku.
Glede na našteto Velocity torej ni:
- Osnova za nagrajevanje timov
- Metrika produktivnosti tima
- Indikator zagnanosti tima
- Sestavljen iz časovnih enot
- Status report za management
- Zagotovilo prihodnje produktivnosti tima
- Indikator ustvarjene poslovne vrednosti
- Indikator uspešnosti razvojnega procesa
RELEASE PLANNING V VEČ TIMSKEM OKOLJU
Kako v Scaled Agile okolju napovemo release glede na to, da vsak tim uporablja lastno definicijo bazne Story Point?
Napoved bomo naredili s pomočjo Burndown grafov*. Iz njih bomo odstranili Story Points vrednosti, ter primerjali njihovo strmino.
* Pred časom sem v članku zagovarjal tezo, da je burnup graf za tim koristnejše orodje kot burndown – zdaj pa delam reklamo za burndown. Trditev še vedno drži. Primerjava Velocity, ki se izvaja z burndown grafom, je orodje za Product Ownerja in Scrum Mastra. Razvojnikom ne nudi koristnih informacij in bi lahko vodila v nekoristno rivalstvo med timi.
Iz grafa vidimo da:
- Tim C bo prevzete uporabniške zgodbe verjetno zaključil pred predvidenim datumom releasa.
- Tim B “zaostaja” in verjetno dela ne bo zaključil pred predvidenim release datumom.
- Tima A in D bosta razvoj verjetno zaključila do predvidenega release datuma.
Kaže, da je (glede na trenutno stanje) verjetnost releasa na predvideni datum nizka. Na voljo imamo več rešitev.
Zmanjšamo scope
Product Owner se sestane z deležniki in poizkuša doseči konsenz glede zmanjšanja obsega planiranega releasa. Mogoče se da izločiti par funkcionalnosti z najnižjo poslovno vrednostjo? Ali pa se določeno funkcionalnost razdeli na dve pod funkcionalnosti. Tisto z višjo poslovno vrednostjo se razvije za trenutni release, funkcionalnost z nižjo poslovno vrednostjo pa se prestavi na enega od naslednjih releasov. Agile to tehniko imenuje Value Based Decomposition.
Zamaknemo release datum
Release se v podjetju pogosto usklajuje z ostalimi povezanimi dejavnostmi kot na primer marketinško kampanjo, predstavitvami investitorjem, dopusti ipd.. Glede na to, da razvoj in izvajanje povezanih dejavnosti potekajo vzporedno, je zamik release datuma pogosto nerealen.
Če pa podobnih odvisnosti ni, oziroma so dovolj fleksibilne, je zamik releasa realna možnost.
Reorganizacija dela
Tretja možnost bi bila aktivacija notranjih rezerv. V našem primeru bi to lahko pomenilo:
- Tim C razbremeni tim B, tako da v razvoj prevzame nekaj njihovih uporabniških zgodb.
- Eden ali več razvojnikov iz tima C se prostovoljno začasno premakne v tim B.
- Pravtako lahko timu B pomagajo razvojniki iz timov A in D (swarming), ki bojo v zadnjih iteracijah pred releasom verjetno manj zaposleni (pogosto stanje pred releasom, ko breme z razvojnikov počasi prehaja na testerje – ni vsak razvojnik tudi tester).
- Timu B se doda nove člane od zunaj ali iz organizacije. Pri tem se je potrebno zavedati, da bo kratkoročno, produktivnost tima B verjetno padla, dokler se novi člani uspešno ne integrirajo v tim (Tuckmanove faze).
Naloga organizacije in Scrum Mastra je, da ustvarita delovno okolje in vzdušje, kjer si bojo člani samo-organizirajočih timov medsebojno pripravljeni pomagati in si prizadevali za dosego skupnega cilja. Da ne bomo preveč naivni; pomembno orodje v tem prizadevanju je tudi nagrajevanje “nivoja višje”.
SKLEP
Velocity je orodje, ki nam v več timskem okolju lahko pomaga planirati release. Nikakor pa ne služi za primerjanje ali celo ocenjevanje produktivnost timov.
Takšna praksa bi vodila do mnogih negativnih vzorcev kot so na primer:
- Timi na skupnem Sprint planning dogodku prevzemajo v realizacijo predvsem preproste uporabniške zgodbe, ki jim bojo hitro generirale maso Story Points. Zahtevne uporabniške zgodbe tako niso več razumljene kot izziv, ampak kot grožnja Velocity metriki in posledično nagrajevanju.
- Čeprav delajo na istem produktu timi zaradi nagrajevanja, ki je vezano na timsko produktivnost, med seboj več ne delijo informacij in znanja. To vpliva tudi na razširjanje dobrih AI praks, ki lahko izredno pospešijo razvojni proces.
- Timi uporabniške zgodbe začnejo ocenjevati z nerealno visokim številom Story Points in na ta način umetno zvišujejo merilo produktivnosti (Velocity). To velja tudi v okoljih kjer organizacija predpiše velikost bazne Story Point.
- Timi določijo zelo majhno bazno Story Point glede na katero potem uporabniške zgodbe lahko vrednotijo z višjim številom točk.
- Timi nimajo motivacije za dopolnjevanje Definition of Done, kar posledično vodi v nižanje kvalitete produkta.
