V preteklem članku sem opisal kako se je kot posledica uporabe AI, ozko grlo software razvoja premaknilo s čakanja na realizacijo uporabniških zgodb (programiranje, code review), na user testing.
Z uporabo vse bolj naprednih AI orodij, nas je sedaj v večjih agilnih okoljih presenetil nov problem, ki bi ga pred enim letom težko predvideli. Gre za problem primerljivosti timske produktivnosti. Presenečenje je toliko večje, ker smo več ali manj vsi razumeli, da smo v zrelih agilnih okoljih pojem produktivnosti (in še posebej njenega merjenja) pustili na smetišču zgodovine. Poglejmo si kje se je zataknilo.
KONTEKST KONFLIKTA
Story points (SP) omogočajo timu relativno ocenjevanje zahtevnosti dela brez pretvarjanja, da je mogoče kompleksno razvojno delo natančno oceniti v urah. Njihova uporabnost pa temelji na določeni stopnji stabilnosti: včerajšnja razmerja med zahtevnostjo različnih vrst dela morajo biti vsaj približno uporabna tudi jutri.
Procesno, story points služijo dvema namenoma:
- Tim z njihovo pomočjo oceni koliko uporabniških zgodb je sposoben prevzeti v sprint z realnim pričakovanjem, da jih bo tudi uspel realizirati
- Produktnemu vodji realizacija (v story points) pomaga pri planiranju datuma releasa in s tem povezanih dejavnosti (marketing, investitorji, prodaja…)
AI je v to enačbo vnesel dodatne spremenljivke. V scaled agile okolju, kjer na istem produktu dela več timov, lahko med njimi obstajajo velike razlike v zrelosti uporabe AI. Nekateri ga uporabljajo samo za pomoč pri programiranju, drugi tudi za pisanje unit testov, spet tretji za regression testing ali code review. Posledično je enota napora potrebna za razvoj neke funkcionalnosti postala še relativnejša, kot je bilo to zamišljeno ob njenem nastanku.
KONFLIKT
Predstavljajmo si da imamo dva razvojna tima:
- Tim A intenzivno uporablja AI (requirements, UX/UI prototipi, programiranje, code review, testing…). Njihov velocity na sprint je 30 SP.
- Tim B, AI uporablja bolj konzervativno ali sploh ne. Njihov velocity na sprint je 40 SP.*
Opomba: razvojni timi imajo lahko različne definicije bazne SP, pa to ne vpliva na planiranje. Pravtako ni kazalec produktivnosti timov.
Predno opišem konflikt, še ena opomba glede nagrajevanja. Razvojne time nagrajujemo “level-up”. To pomeni, da v eno timskem projektu ne nagrajujemo osebnih doprinosov, ampak tim kot celoto. Ta skupna odgovornost vzpodbuja izmenjavo informacij znotraj tima in medsebojno sodelovanje članov na poti do skupnega cilja (nagrade). V več timskem okolju, pa kot celoto nagrajujemo skupino timov, ki delajo na istem produktu. Ne merimo ali nagrajujemo uspešnosti posameznih timov.
PRIMER
Smo na več-timskem backlog refinement ali sprint planning dogodku. Timi ocenjujejo zahtevnost uporabniških zgodb v product backlogu. Slej ko prej se bo tim A začel spraševati, zakaj je tim B neko uporabniško zgodbo ocenil z 21 SP (polovica njihove kapacitete za prihajajoči sprint), če bi ga pa sami ocenili samo z 8 SP kar je manj kot tretjina njihove kapacitete za prihajajoči sprint. Se tim B izogiba delu? Se ne trudijo dovolj? Niso “team players”?
Ta vprašanja so povsem legitimna, a istočasno seme neizogibnega konflikta. Govorimo o objektivni razliki v produktivnosti timov A in B. Te razlike ne zakrije niti različna velikost bazne SP, ki jo uporabljata tima. AI je povzročil razliko v timski produktivnosti za katero v agilu izraz še ne obstaja.
Tradicionalno smo se v podobnih primerih zatekli k trditvi, da agilnim timom ne merimo kvantitativne produktivnosti, ampak poslovni učinek rešitve za naročnika. Merjenje produktivnosti nam je v misel takoj priklicalo podjetja, ki so svoje time nagrajevala po vrsticah napisane kode. Mislim, da te prakse ni potrebno posebej komentirati.
V primeru timov A in B, diferenciranje med njima po ustvarjeni poslovni vrednosti, ne prenese stika z realnostjo. Naročnik na sprint review ne ocenjuje dela tima A in B ločeno, ampak ocenjuje integrirani produktni inkrement. Naročnika ne zanima katero funkcionalnost je razvil tim A in katero tim B. Pomembno je le to le to, da inkrement rešuje njegov poslovni problem.
Predstavljajmo si, da je tim A naredil UX workflow in UI, tim B pa API, integracijo in podatkovni model. Nova integrirana funkcionalnost je naročniku ustvarila 100k poslovne vrednosti. Koliko od te vrednosti je ustvaril tim A in koliko B?
Tim A se seveda zaveda, da so nagrajevani “level-up” in da je v njihovem interesu sodelovati s počasnejšim timom B, a bojo njihovi zadržki ostali. Če s strani organizacije ta dispariteta ne bo naslovljena, bo to slej ko prej vodilo v zamere in otežkočilo sodelovanje med timoma. Ali smo prišli do točke, ko bomo ponovno začeli meriti produktivnost posameznih timov?
KAKO LAHKO PODJETJE POMAGA
Predpostavimo, da smo potrdili, da je ekipa A v resnici bolj produktivna zaradi obsežnejše uporabe AI. V tem primeru se podjetje najprej mora nehati slepiti, da bo ekipa B v nedogled lahko delovala na “stari” način. Sociološki konflikt, ki nastaja zaradi različne produktivnosti timov, ne bo izginil sam od sebe, ampak se bo poglabljal dokler zaradi tega ne bo trpela celotna organizacija. Ekipa B torej mora spremeniti svoj način dela. Izziv za podjetje pa je, kako to izvesti čim bolj taktno.
V nastalem konfliktu lahko prepoznamo tri vrzeli. Bom uporabil kar njihove angleške izraze, ker se mi zdi, da jih nima smisla prevajati v slovenščino:
- Measurement gap: organizacija nima primerne metrike, s katero bi razliko v produktivnosti legitimno predstavila. SP med timi niso primerljivi, poslovna vrednost pa je skupna.
- Capability gap: tim A zna z AI narediti nekaj bistveno učinkoviteje kot tim B.
- Fairness gap: tim A opaža, da mora zaradi B nositi večji del skupnega bremena.
Cilj je pomagati timu B dvigniti produktivnost brez pritiska ali povzročanja občutka krivde.
MEASUREMENT GAP
Organizacija v resnici ne potrebuje nove metrike produktivnosti. Potrebuje mehanizem, ki bo pokazal, ali obstaja boljši način dela in ga nato razširil po celotnem sistemu.
Predmet primerjave naj ne bo output timov, ampak njihov način dela. Naša ugotovitev je lahko na primer:
“Kaže, da tim A uporablja način dela, ki ga B še ne pozna. Kaj je ta način dela in ali ga lahko razširimo na ostale time?”
Če se na primer izkaže, da je AI assisted regression testing dobra praksa, se iz tega ne naredi KPI, ampak se jo ponudi v uporabo ostalim timom. Seveda mora podjetje zagotoviti mehanizme in pogoje razširjanja dobrih praks.
To so lahko na primer:
- pair programming kjer se razvojnik ekipe A pridruži razvojniku iz B in mu pomaga pri uporabi dobrih AI praks,
- deljena knjižnica koristnih AI promptov,
- Lean Coffee,
- Communities of Interest / Practice,
- Scouts,
- Travelers,
- “Slack time”. Več o tem nižje v članku.
Več o opisanih orodjih, si lahko preberete v tem članku. Ena boljših zbirk primernih tehnik je zbrana pod imenom Liberating Structures.
S časom pričakujemo, da bo identificirana dobra praksa postala standardni del razvojnega sistema.
Samoorganizacija timom daje avtonomijo pri izbiri načina dela, ne pa pravice do trajnega ignoriranja dokazano učinkovitejšega načina dela.
CAPABILITY GAP
Pomislimo kako bi danes gledali na tim, ki a-priori zavrača uporabo CI/CD, version control ali unit testov? Na neki točki je določena praksa postala del razvojnega standarda. Isto velja za dobre prakse povezane z AI.
Na tej osnovi lahko definiramo AI capability zanko, ki nam bo pomagala formalizirati dobre prakse:
- Opažanje: med timi se je pokazala večja razlika pri oceni zahtevnosti primerljivega tipa dela.
- Preverjanje: ugotovimo kaj je razlog za razliko. To ni nujno uporaba AI. Lahko je na primer drugačna problemska domena, legacy koda, tehnični dolg, kompetence, odvisnosti ipd.
- Deljenje znanja: učinkovitejši tim predstavi svoj workflow ostalim timom. O orodjih za to sem pisal v rubriki Measurement Gap.
- Eksperimentiranje: ostali timi novi workflow preizkusijo v svojem okolju.
- Standardizacija: če se izboljšava dokaže tudi pri ostalih timih, postane del standardne inženirske prakse.
To je pomembno tudi zato, ker prednost tima A danes, ni nujno njegova prednost tudi jutri. Naslednji mesec lahko tim B odkrije bistveno boljši AI testing workflow in postane vir znanja za A.
Z opisano zanko smo postavili osnovo za organizacijsko učenje. V Lean terminologiji bi to imenovali Yokoten.
FAIRNESS GAP
Napaka bi bila, če bi organizacija vsak prihranek, ki ga ustvari AI, takoj pretvorila v zahtevo po večjem outputu. S tem bi odstranili ravno tisto kapaciteto, ki jo potrebujemo za izboljševanje in širjenje AI znanja po organizaciji.
Agile ne pričakuje 100% izkoristka razvojnikovega časa. Še več t.i. slack time je celo zaželen. Razvojniki ga lahko izrabijo za dodatno izobraževanje, lastne projekte, communities of practice, Lean Coffee ali katero koli od množice skupinskih dejavnosti. Želja po ohranjanju slack time, je posledica spoznanja, da neprestani cikli optimizacije dela slej ko prej privedejo do t.i. death march situacije, ki za razvojnike ni vzdržna.
Tim, ki z novimi pristopi prihrani čas, mora del tega časa dobiti na voljo v obliki “slack time”.
V tem kontekstu največja nevarnost AI v scaled Agile okolju ni, da bodo nekateri timi postali produktivnejši od drugih. Nevarnost je, da bodo produktivnejši timi zaradi dodatne kapacitete hitreje eksperimentirali in s tem postajali vedno bolj produktivni, medtem ko bodo manj produktivni timi zaradi pomanjkanja časa za učenje vedno bolj zaostajali. Naloga organizacije zato ni izenačevanje velocity, ampak preprečevanje razkoraka s sistematičnim širjenjem znanja in ohranjanjem kapacitete za učenje.
Zato slack time ne sme biti samo nagrada za že doseženo produktivnost. Organizacija mora začasno ustvariti kapaciteto za učenje tudi pri timih, ki zaostajajo. Če bojo ti 100% izkoriščeni te kapacitete ne bo. Posledično pričakujemo, da bojo hitrejši timi del svojega slack time posvetili deljenju znanja s počasnejšimi timi. Navsezadnje je to zaradi level-up nagrajevanja tudi v njihovem interesu.
SKLEP
Za rešitev med timskih konfliktov, ki so posledica različne uporabe AI (in s tem različne produktivnosti), ne obstaja univerzalni recept. Predstavljam pa svoje predloge:
- Pomagamo si z dobrimi praksami sodelovanja in razširjanja znanja znotraj organizacije. Tukaj bi poudaril uporabo Travelers.
- Zagotovimo, da kljub postopnem zviševanju produktivnosti ohranjamo “slack time”, ki je gonilo bodočih izboljšav.
- Preprečimo tekmovalnost, ki bi počasnejše time potisnila v obrambni položaj.
- Planirajmo naloge v naprej tako, da (začasno) počasnejši timi ne bojo ustvarjali odvisnosti za hitrejše time.
- Uporabljajmo vmesnike in simulacije (mocks, stubs), da lahko hitrejši timi razvijajo naprej brez čakanja na počasnejše time.
- Določimo jasne pogodbe API, ki omogočajo samostojnejše delo timov.
- Tolerirajmo določen razkorak v produktivnosti timov. Bazična znanja, ki jih ohranjajo timi z nižjo uporabo AI, morajo ostati v organizaciji. Ko jih bo ta potrebovala, bojo še vedno na voljo interno.
P.S. Še nekaj o story points
Če je bralec slučajno prišel do sklepa, da je uporaba story points po vsem povedanem nesmiselna, bi želel nasloviti še to dilemo.
Kljub pomoči AI, realizacija posameznih funkcionalnosti še vedno zahteva določen napor. Potrebno je napisati prompte, povezati agente, postaviti omejitve, debugging, security review. Ta napor se z nekaj prakse pravtako da oceniti in pretvoriti v story points, ki nato služijo dvema na začetku omenjenima funkcijama.
Vsebinsko pa je korist ocenjevanja zahtevnosti uporabniških zgodb mnogo večja kot samo Fibonaccijeva vrednost, ki je njen neposredni rezultat. Glavna korist ocenjevanja je razgovor med tem procesom. Tim uporablja na primer planning poker kjer imajo člani z določenimi pomisleki, ali specifičnimi znanji možnost pojasnila, zakaj se njihova ocena bistveno razlikuje glede na ocene ostalih članov.
Informacije pridobljene v tem razgovoru vodijo v proces:
- identifikacije in odpravljanja rizikov,
- razširjanja znanja in informacij znotraj tima,
- identifikacijo učinkovitih AI promptov,
- konsenz glede posredovanja acceptance kriterijev AI sistemu,
- buy-in udeležencev, ki so dosegli konsenz glede zahtevnosti uporabniške zgodbe,
- identifikacije individualnih nalog (taskov), ki so potrebni za realizacijo uporabniške zgodbe,
- identifikacijo medsebojnih odvisnosti taskov in odvisnosti z drugimi uporabniškimi zgodbami,
- UX optimizacijo
Ocena v story points torej ni le številka, ki pomaga pri planiranju sprinta in releasa, ampak celoten proces timskega usklajevanja, ki omogoči lažje in učinkovitejše delo.
