Agile or not Agile? Why Agile?
„It’s the question that drives us, Neo.”
Trinity, The Matrix, 1999
Nu trebuie să ai copii mici ca să știi că cea mai grea întrebare cu care ne confruntăm în viață este exasperantul dar și dulcele lor „de ce?”. Motivația noastră în ceea ce facem în fiecare zi este strâns legată de răspunsurile primite și date la această întrebare.
Cum transpunem aceasta în business și Agile? Una dintre regulile prin care cadrul de dezvoltare Scrum ne ajută să primim și să dăm aceste răspunsuri în activitatea noastră profesională este cerința ca fiecare ședință de planificare a sprint-ului să formuleze un scop al sprint-ului (Sprint Goal). Și este aplicabilă nu doar în dezvoltarea de software, ci în orice alt domeniu al muncii creative. Din păcate însă, în multe planificări de sprint se pierde din vedere această regulă simplă! Si da, răspunzători pentru această lipsă sunt Scrum Master-ii!
Product Owner – rol esențial în Agile
În destule cazuri, Product Owner-ul vine în această ședință nu cu un scop de îndeplinit, ci cu o listă cu lucruri de implementat. Deși scopul sprint-ului pare un concept oarecum ezoteric și dificil de stăpânit, dacă Product Owner-ul are lista cu lucruri la care ar vrea el să lucreze echipa de dezvoltare în următorul sprint, atunci el știe deja și scopul sprint-ului: acesta nu este decât răspunsul la întrebarea „de ce aceste elemente din Product Backlog și nu altele?”. Simplu, nu? Altfel spus, scopul sprint-ului descrie misiunea de îndeplinit, iar lista cu lucruri de făcut pașii necesari îndeplinirii acesteia.
Cred că de departe cel mai greu de implementat rol în Scrum este cel de Product Owner. Tocmai pentru că acest rol trebuie să poată răspunde oricând la întrebarea „de ce?”
- De ce dezvoltăm acest produs?
- De ce aceste termene limită?
- De ce unele lucruri au prioritate mai mare și altele mai mică?
- De ce trebuie făcute aceste lucruri acum?
- De ce aceste lucruri și nu altele?
Din nefericire, majoritatea covârșitoare a Product Owner-ilor pe care i-am întâlnit sunt de fapt analiști de business cu ceva mai multă autoritate. Aceștia sunt obișnuiți să furnizeze echipei de dezvoltare cerințe și detalii despre ele – adică ce trebuie făcut . Ce lipsește din discuție este motivația din spatele acelor cerințe, faimoasa valoare pentru business (Business Value).
Sprint-ul în Agile
Planificarea sprint-urilor cu ajutorul unor scopuri de îndeplinit în timpul execuției oferă următoarele multiple avantaje.
În primul rînd, Product Owner-ul poate conduce dezvoltarea produsului cu o listă de scopuri de îndeplinit. Adică o foaie de parcurs a produsului (Product Roadmap) – și nu doar cu o listă de livrări (Release Plan). Confuzia între cele două concepte este larg răspândită. Aceasta, probabil și pentru că Product Owner-ul este de prea multe ori doar un furnizor de cerințe! Adevăratul rol al Product Owner-ului este de gestionar al valorii oferite de produs.
În al doilea rînd, echipa de dezvoltare descoperă împreună cu Product Owner-ul care elemente din Product Backlog trebuie implementate pentru a atinge scopul propus. Acest fapt ajută la creșterea motivației, deoarece oamenii nu se mai simt prizonieri în roata de hamster a implementării, ci capătă un sentiment de proprietate mai accentuat asupra produsului.
În al treilea rînd, caz deloc neobișnuit, în cazul în care capacitatea echipei din sprint-ul care tocmai începe nu permite realizarea tuturor elementelor din backlog necesare pentru atingerea scopului. Product Owner-ul poate decide încă de la planificare – deci înainte de începerea execuției – dacă ceea ce se poate implementa realizează îndeajuns de mult din scop sau poate acesta trebuie înlocuit cu un alt scop, cu șanse mai mari de realizare.
Suplimentar, dacă pe parcursul execuției sprint-ului echipa ajunge la concluzia că nu se vor putea implementa toate elementele din Sprint Backlog asumate la planificare, Product Owner-ul poate decide ușor, împreună cu echipa, dacă se cere oprirea anormală a sprint-ului (Abnormal Sprint Termination).
În loc de concluzie
Acestea fiind spuse, trebuie avută tot timpul în vedere și maturitatea celor implicați și a produsului în dezvoltare. Unele echipe au nevoie să fie ghidate îndeaproape și de aceea poate este o idee bună ca la planificarea sprint-ului să li se prezinte o listă clară cu lucruri de făcut. Echipele cu maturitate mică, de altfel, se plâng tot timpul că fie Product Owner-ul, fie utilizatorii finali nu știu ce vor. Echipe mature, însă, profită de această situație pentru a-și aduce propria lor contribuție! Această contribuție poate merge până la a sugera Product Owner-ului un scop pentru sprintul curent. Oricum, Product Owner-ul are ultimul cuvânt atât asupra scopului sprint-ului, cât și asupra elementelor din backlog alese pentru a-l îndeplini.
Ce se întâmplă de fapt? În munca ne-creativă de obicei „se aruncă” cu oameni (și alte resurse) în probleme, cu speranța că astfel se rezolvă problema! În munca creativă, trebuie să schimbăm paradigma! Ne dorim „să aruncăm” cu probleme în oameni! Nu doar pentru că ei sunt experți în ceea ce fac, dar și știu mai mult decât șefii lor despre muncă. Iar Scrum ne ajută să facem aceasta cu ajutorul formulării de scopului de îndeplinit în fiecare sprint.
Ne putem educa astfel să abordăm munca nu doar ca o căutare de soluții tehnice pentru implementarea de funcționalități! Munca noastră va deveni astfel o descoperire continuă de funcționalități, ca soluții pentru probleme de business.
Alftel spus, VALOARE!
Lean-Agile Coach | PMP, CSM, LSSGB, SPC4, PMI-ACP
