Pentru mine, orice element din Scrum, Kanban, Agile trebuie supus criticii. Nu există adevăr incontestabil, și chiar și cele mai luminate minți ale lumii pot greși în procesul lor de învățare. Una din tezele principale din Scrum este angajamentul făcut de echipă în Planificarea Sprintului. Cred că ideea de „commitment” este supralicitată. Angajamentul este pe înțelesul tuturor, dar mai ales pe înțelesul Scrum Master-ilor care tocmai au migrat de la șefia de proiect sau al Respsonsabililor de Produs sau al managerilor care vor să impună Scrum, cadrul hiperproductiv.
Calitatea
Dacă ar fi să mă întrebați pe mine, acesta este efectul cel mai nociv. Indiferent de cauză, chiar dacă este angajamentul lor, când oamenii simt o tensiune dincolo de limitele benefice unui ritm constant vor avea tendința să livreze doar în parametrii imediat măsurabili. Cu alte cuvinte, nimic mai mult față de ce se va inspecta în Revizuirea Sprintului. De fiecare dată când s-a ținut de livrarea unui perimetru în cadrul sprintului Definiția lui Finalizat (Definition of Done) n-a fost respectată. N-am văzut o echipă care să facă diferit. Definiția lui finalizat abia dacă mai este urmărită prima dată. Deja a doua oară toată lumea acceptă că s-au făcut niște compromisuri. Mai întâi încercăm să nu le pierdem din vedere, suntem încă o echipă responsabilă, și le trecem în Backlog-ul de produs, ca să le luăm în sprintul următor, sau mai târziu. Mai târziu, nici nu mai contează. Bubele create sunt oricum mult prea mari, pentru a fi corectate ușor și necesită refactoring masiv.
De fapt, angajamentul echipei de a face un produs de o calitate excelentă se transformă în angajamentul echipei de a livra perimetrul dat.
Mai multe informații în articolul Calitatea este cel mai important slogan al nostru!
Capacitatea de prognoză
Prima nevoie a Responsabilului de Produs, și nu doar a lui, a managementului, a investitorilor, etc. este să aibă vizibilitate asupra progresului și să se poată baza pe istoric pentru a putea răspunde la întrebarea următoare: „dacă nu schimbăm nimic, când reușim să livrăm funcționalitatea/perimetrul X? Câteodată nu se poate, însă în majoritatea cazurilor se poate. Această nevoie este exprimată și prin cel de-al zecelea principiu din manifestul agil: „Simplitatea–arta de a maximiza cantitatea de muncă nerealizată–este esențială”. Dacă pe ultimele 5 sprinturi am reușit să livrăm un perimetru mediu de mărimea X, și dacă nu schimbăm nimic în viitoarele sprinturi, avem șanse mari să livrăm întreg Backlog-ul rămas în Y sprinturi.
Însă ce se întâmplă dacă într-un sprint echipa lucrează 12 ore pe zi din cauza unei greșeli în Planificarea Sprintului sau din cauză că a învățat ceva în timpul Sprintului? Vor reuși în următorul sprint să facă tot 12 ore pe zi? Care este viteza lor reală? Și știm că această dificultate de prognoză nu este o problemă de aritmetică simplă. Ceea ce o echipă poate realiza în 12 ore nu este egal ceea ce o echipă poate realiza în 2 ore de 6 ori.
Mai multe informații în articolul iterațiile cu lungimea fixă.
Angajamentul față de scopul sprintului
Recent am auzit de ideea trecerii de la un angajament față de un perimetru funcțional sau story points, la un angajament față de obiectivul sprintului. Cred că este greșit. Obiectivul sprintului este dat ca să ghideze echipa și întocmai pentru a asigura un grad de flexibilitate în luarea deciziilor în timpul sprintului.
O chestiune de responsabilitate
Responsabilul de Produs, învățând că ceva din ce și-a dorit inițial pentru sprintul în curs nu mai are sens, poate anula sprintul.
La fel și echipa de dezvoltare poate învăța în timpul sprintului că este mai bine să facă altfel și își va dori să se apuce de acest altfel imediat. Ce s-ar întâmpla bun dacă echipa ar continua să lucreze bazându-se pe ipotezele/deciziile luate în Planificarea Sprintului, știind că nu așa trebuie făcut? Exact, îi va deresponsabiliza: „noi știam că nu așa se face, dar așa e în Scrum” sau „așa sunt regulile” sau „nu ne-a ascultat nimeni”.
Dacă acest altfel necesită și modificarea perimetrului funcțional din Sprint, ceea ce este puțin probabil, ei pot solicita Responsabilului de Produs anularea sprintului, dar decizia nu este a lor.
De unde vine confuzia?
În versiunea ghidului scrum din 2010 se vorbea despre „commitment”:
„The Team has committed to a Sprint Goal, and to these Product Backlog items.”, însă în același ghid erau prezente și sfaturi precum cel de mai jos:
În 2011 și până acum, „commitement” a fost înlocuit cu „forecast”:
The Development Team works to forecast the functionality that will be developed during the Sprint.
O chestiune de valori
Probabil că și fabula cu găina și porcul a alimentat eronat confuzia. Angajamentul, așa cum ar trebui să reiasă din această învățătură, transcede dincolo de sistemul de valori al echipelor Scrum.
Implicit, regăsim „angajamentul” în cele 5 valori Scrum: „pentru că avem controlul asupra destinului nostru, ne angajăm să reușim” – nu chiar ca în articol, dar exact așa cum văd eu lucrurile.
De reținut: fără ca echipa să aibă controlul, nu există angajament.Altele
Angajamentul echipei de dezvoltare față de un perimetru dat încalcă atât principiile și valorile din manifestul agil, cât și cadrul Scrum. Ar fi atât de multe de zis: sistem de tip trage, ritm susținut, motivația echipei, etc.
Am reflectat mult la acest subiect în 2014, și nici măcar mândria echipei de a nu pierde nu mi se mai pare un motiv suficient de bun. Descurajez ferm agățarea echipei de perimetrul discutat în Planificarea Sprintului pentru că determină un mod de gândire în care învățatul și acceptarea realității sunt corelate cu pierderea.
Va urma…
Angajamentul față de perimetrul funcțional stabilit în Planificarea Sprintului
Dacă doriți să aflați mai multe despre mine, Cornel Fătulescu, sau proiectele în care sunt implicat, vă invit să mă descoperiți și ca Chief Platform Officer la Pentalog, să mă urmăriți pe Facebook, ca investitor la wanttolearn, să citiți unul dintre primele articole despre mine și să mă contactați urmând ghidul de pe pagina de contact.
Acest articol a fost citit de 3356 ori