by Iată ca Scrum Guide a ajuns la editia a 7-a, din februarie 2010 și pana în prezent. O „cadenta” care reflecta natura adaptiva a acestui concept, dar și o preocupare ca lucrurile sa își pastreze spiritul în care au fost ele gândite de către Ken Schwaber & Jeff Sutherland. De-al lungul timpului, modificarile aduse au avut nivele diferite de impact asupra ghidului. De exemplu, dacă editia a treia a venit doar cu niște ajustari minore, editia a cincea a adus cu ea cele cinci valori ale cadrului de lucru Scrum, deci un element major al acestei filozofiei.
Aceasta a 7-a editie este una mult mai scurta decat precedenta, autorii concentrand ideiile lor in numai 14 pagini, comparativ cu cele 19 pagini din ghidul 2017 (deci cu 25% mai scurta). Ghidul devine din ce in ce mai flexibil si mai putin specific / mai putin prescriptiv.
Haideți sa vedem ca aduce nou aceasta editie și în ce măsura aceste noutăți sunt unele definitorii pentru perioada viitoare.
Purpose of the Scrum Guide
„Together, we stand behind it.” Aceasta este o afirmatie profunda înca din primul paragraf , care arata angajamentul lui Ken Schwaber si Jeff Sutherland de a continua sa lucreze la filozofia Scrum într-o maniera agila (through small, functional updates). Este și o invitație, către toți cei care găsesc în Scrum un cadrul de lucru (framework) potrivit și benefic pentru echipele cu care lucreaza.
Dacă în versiunea din 2017, acest capitol se intindea pe parcursul unui singur paragraf, ghidul anului 2020 manifesta în mod ceva mai amplu atât grija pentru trecut, dar mai ales pentru viitor și pentru modulul în care acest ghid (în general), dar mai ales practicile Scrum (în particular) sunt utilizate. Găsim aici o recomandare ferma care vizeaza atat conceptele cheie (nucleu), cat și elementele și practicile care, odată ignorate, limiteaza beneficiile Scrum și acoperă probleme în loc sa le rezolve.
Citind printre rânduri, pare ca autorii atrag atenția asupra unor lecții invatate în timp, cel puțin în ultimii 3 ani. Vorbim aici despre situații în care adoptarea sau utilizarea Scrum au dat greș, datorită faptului ca reguli de baza au fost ignorate sau ca elemente ale Scrum au fost scoase din context. Autorii insista asupra faptului ca noi idei, sabloane sau procese pot fi descoperite aplicand acest cadru de lucru, dar ideea care pare să se desprinda este aceeași: „Aplicati în prima faza Scrum așa cum este el descris în acest ghid, cu regulile și valorile sale initiale; abia după ce aveți succes în a le stăpâni, adaptati-le și jucati-va cu ele.” Se revine deci la idea conturata prima oara în cea de a doua iteratie, din Iulie 2011, când o nota a ghidului arata ca „Scrum’s roles, artifacts, events, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum ”.
O alta idee care se desprinde din acest capitol este legată de amploarea fenomenului Scrum și mai ales a extinderii utilizarii Scrum dincolo de dezvoltarea de software. Este adresata în mod explicit invitația de a ne alătura comunității utilizatorilor Scrum, indiferent de domeniul de activitate, atât timp cât găsim beneficii în utilizarea acestui cadru de lucru. Ca o manifestare concreta a acestei invitatii, apare propunerea de a utiliza cuvantul „Developers” in locul oricarui alt termen ce desemneaza specialistii care fac munca
Scrum Definition
Primul aliniat deja starneste o controversa interesantă, una pe care o vom regăsi în mod constant de-a lungul ghidului 2020. Este vorba de valoare (value) și de ideea de a genera valoare, fata de versiunea 2017 în care „livram produse cu cea mai mare valoare posibila”. Chiar dacă diferența este una subtila, conceptul de a livra pare sa fi evoluat către generarea de valoare. Personal, eu o vad ca un mod de a vorbi despre plus-valoare (formularea din 2020) fata de a livra valoarea (de a pune cap la cap actiuni care livreaza). Iar generarea de valoare este extinsa în ghidul 2020 către echipe și organizații, dincolo de oameni (people).
Iarasi interesantă este referinta directa, fără echivoc, a unui Scrum Master, care sa dezvolte și sa intretina un mediu de lucru în care Product Owner-ul și Echipa Scrum în general sa munceasca cu succes. Partea interesantă este accentul care pare să fie pus pe Scrum Master, ca actor principal al actiunilor din framework. Mai mult, cred ca acest paragraf răspunde clar întrebarii dacă Scrum Master-ul este sau nu necesar în cadrul echipei Scrum. Chiar dacă în proiectele adaptive, responsabilitatile unui PM sunt împărțite între mai multe roluri (3 asa cum erau in Scrum), se pare ca Scrum Master-ul primește chiar in Definitia Scrum un pol de putere / de importanta care pana acum a parut oarecum neclar pentru unii.
Dacă în versiunea din 2017, autorii spuneau în mod clar despre Scrum ca este „simplu de înțeles” și „greu de aplicat”, în ghidul din 2020 lucrurile par a fi doar „simple”, în ceea ce privește Scrum. Este un nou indiciu ca Scrum a câștigat inimile și adeziunea unui numar din ce în ce mai mare de adepti, care au implementat cu un succes mai mare sau mai mic acest cadrul de lucru. Cu toate acestea, se revine insistent asupra faptului ca Ghidul Scrum este incomplet, pentru a oferi libertate celor care doresc sa adapteze, asta după ce în primul capitol s-a atras atenția asupra modului în care inovatia trebuie aplicata în acest cadrul de lucru.
Uses of Scrum
Acesta este un întreg capitol care a fost eliminat din ghidul anului 2020. Interesant, avand in vedere ca el a aparut prima oara in Ghidul Scrum in 2017. Dacă în 2017 încă se simțea nevoia de a enumera domeniile în care era utilizat Scrum, iata ca în 2020 este adresata o invitație catre toate echipele care contribuie la dezvoltare de valoare, invitatie de a se alătura acestei miscari. Aceasta schimbare este de altfel în acord cu declarația din primul capitol, „Purpose of the Scrum Guide”. Referinte privind cât de eficace este Scrum în transferul de cunoștințe, prin mecanisme atât iterative cât și incrementale, sunt regasite ulterior, pe tot parcursul ghidului.
Scrum Theory
„Scrum is founded on empiricism and lean thinking”. Una din marile revelatii ale acestei editii este fundatia / descendenta declarata din filozofia Lean, afirmata în capitolul „Teoria Scrum”. Dacă pana în prezent, aceasta descendenta a fost adusă în discuție tangential in alte lucrari (cel mai pregnant în „Agile Practice Guide 2017”), autorii afirma acum în mod explicit ca este nevoie ca aplicarea Scrum sa conduca la reducerea pierderilor (waste) și la concentrarea pe lucruri esentiale – parte centrala a filozofiei Lean.
Un alt element interesant al acestui capitol, este anticiparea informațiilor privind evenimentele Scrum, ca suport pentru inspectie si adaptare, cu nominalizarea Sprintului din Scrum ca fiind containerul / recipientul (mai degraba contextul) ce cuprinde cele 4 evenimente formale Scrum. Dacă în ghidul 2017 aceasta informație este regasita în capitolul „Scrum Events”, iata ca acum ea este referita in prima faza ceva mai devreme, în acest capitol care face referire la teoria Scrum. Este ca si cum se doreste sa se intareasca importanta acestor practici, ca fiind o baza a teoriei Scrum.
Ca și în ghidul din 2017, urmează o prezentare a celor 3 „stalpi” pe care se sprijina Scrum, însă chiar și aici vom găsi cateva indicii interesante depre modul în care a evoluat Scrum pe parcursul a 3 ani.
Transparency
Primul „stalp” prezentat este, ca și în 2017, transparenta. Cu toate acestea, ca un semn de recunoaștere a maturitatii celor care aplica Scrum, nu mai sunt enumerate exemple concrete despre cum transparenta asista acest cadru de lucru. Acesta poate deveni și un prilej de reflectie pentru cei interesati de Scrum; Este suficient sa citim doar ghidul din 2020? Poate ghidul din 2017 sa ofere indicii la care nu ne-am gândit si care sunt prezentate (sau nu) si in editii precedente?
Un alt element interesant, specific tuturor celor 3 stalpi, este tranzitia declarata de autori intre stalpii Scrum. Apare de fapt un soi de „ierarhie” a acestora, nu ca importanța cât mai ales ca ordine iterativa în care au loc. Iată cum apare declarația „Transparency enables inspection”.
Inspection
Un nou semn de maturitate apare în capitolul aferent inspectiei. Dacă în 2017 ni se spunea ca artefactele / elementele tangibile ale Scrum trebuie inspectate cât mai des, ca un „how”, deja în 2020 accentul este pus ușor diferit, mai degrabă ca un „where to look”. Mai mult, referirea din 2017 la inspectori cu abilitati pentru aceasta (skilled inspectors) este inlocuita cu o referire la cele cinci evenimente Scrum care nu doar faciliteaza, dar chiar provoaca inspectia și ulterior adaptarea.
La final avem din nou un element de tranzitie, „Inspection enables adaptation” care arata ca inspectia fără adaptare este un efort fără rost.
Adaptation
Acest capitol este un alt indiciu al diversitatii pe care o capata aplicarea Scrum ca un cadru de lucru pentru echipe. Dacă în 2017 se vorbea despre „the process or the material being processed”, în 2020 se pune un mai mare accent pe domenii de activitate orientate pe produs, prin „the process being applied or the materials being produced”. Chiar dacă nu se mai enumera cele patru evenimente Scrum care facilitau inspectia și adaptarea, se vorbește în schimb despre ideea de baza a echipelor care trebuie să fie „empowered or self-managing ” pentru a se putea adapta cu ușurința schimbarilor. Legat de termenul self-managing, avem o alta schimbare cu implicatii adanci. Daca in 2017 s-a vorbit despre echipe „self-organizing”, iata ca in 2020 vorbim despre echipe „self-managing”, care in afara de „who” si „how”, decide si ce („what”) in privinta muncii sale.
Scrum Values
După enumerarea celor cinci valori ale Scrum, autorii reiau descrierea narativa a modului în care aceste valori sunt puse în practica activitatii echipelor. Dacă în 2017 se vorbea despre persoane, care se angajeaza în mod personal („People personally commit ”), în 2020 se vorbește despre echipa și modul în care aceasta se angajeaza și se sprijina reciproc:
- The Scrum Team commits…
- Their primary focus is…
- The Scrum Team and its stakeholders are open…
- Scrum Team members respect…
- The Scrum Team members have the courage
Este unul din primele semnale din noul ghid, despre „orientarea” polului de interes către Scrum Team.
Nu știm dacă enumerarea modificata a secventei celor cinci valori este intenționată sau nu. În mod evident nu credem ca autorii au dat mai multă importanța unei valori asupra alteia, însă aceasta schimbare poate fi un prilej de reflectie. De exemplu, poate ca în 2017 încă se simțea nevoia de curaj pentru adoptarea Scrum, pe când în 2020, odată cu adoptarea pe scara mai larga a acestui cadru de lucru, este vizat focusul pe care echipa trebuie sa îl acorde activitatii din cadrul Sprintului, pentru a obtine cel mai bun progres către obiectivul Sprintului.
The Scrum Team
Un alt capitol care a căpătat un continut mai amplu este cel dedicat echipei Scrum. Încă din primul paragraf suntem canalizati pe câteva informații interesante:
– în primul rând, trecerea de la Development Team la Developers; aceasta schimbare de titulatura, anunțată încă din primul capitol al ghidului, arata deschiderea pe care Scrum o are către alte domenii de activitate decât cel software și deschide ușa pentru orice domeniu în care se dezvolta ceva, indiferent ca vorbim de serviciu sau produs.
– o alta modificare conceputuala majora în ghidul din 2020 este absenta referirilor la roluri. In ghidul 2017 exista 6 astfel de referiri, pe când în ghidul actual se vorbește de responsabilitățile (accountabilities) de Developer, Product Owner și Scrum Master. Pare ca se evita din nou elementul prescriptiv puternic (acela de rol) în locul careia se utilizeaza conceptul de responsabilitate (accountabilities). Un motiv ar putea fi unitatea echipei. Poate ca echipa nu era suficient de unita din cauza existentei acestor roluri. O alta explicatie poate fi legata de natura limitativa a unui rol, ca o haina stramta imbracata de cineva care performeaza rolul. Un rol este de regula asociat unui script sau unei liste de actiuni de realizat / de indeplinit. Nominalizarea responsabilitatii in locul unui rol aduce o mai mare libertate de miscare privind natura actiunilor pe care le intreprindem pentru a ne atinge obiectivele.
– este foarte clar stipulata absenta oricaror ierarhii sau sub-echipe, fata de echipa Scrum.
– este enuntata pentru prima oara notiunea de Product Goal (care nu apare în editia din 2017), notiune care alături de Sprint Goal va fi un lait-motiv bine reprezentat în acest ghid.
– se vorbește despre dimensiunea echipei Scrum. In ghidul din 2017 aveam informații despre un numar de componenti ai echipei de dezvoltare (Development Team), structurat ca un subcapitol separat. Aici erau aratate limite inferioare și superioare (trei și respectiv noua membri). Acum avem aceste informații în descrierea echipei Scrum, pastrand însă motivatiile pentru care aceste echipe nu trebuie să fie nici prea mari și nici prea mici. Ceea ce este cu adevărat interesant este propunerea de scalare a echipelor Scrum, care sa impartaseasca același Product Backlog, Product Owner și Product Goal. Observam aici fapul ca se lasa o libertate deplina privind posibilitatile de scalare, fara a impune pentru aceasta Nexus sau SAFe sau LESS.
– un alt concept adus în discuție este cel de „sustainable pace” pe care îl întâlnim în eXtreme Programming si in Agile Manifesto (adus acolo din XP, probabil). Este inserat în text în contextul lucrului în Sprinturi, în vederea imbunatatirii focusului și consistentei muncii.
Developers
Descrierea echipei de dezvoltare, sub noua titulatura de Developers, aduce și ea un semn de maturitate a Scrum. Deja în 2020 sunt enumerate responsabilitati, în locul caracteristicilor unui rol, așa cum era în editia din 2017. Știm deja ca echipa este multi-functionala, și auto-organizata, cu o structura plata și fără subechipe. De aceea, în 2020 vorbim despre responsabiliti de:
– planificare, cu output principal Sprint Backlog,
– de aderare la Definition of Done ca element de asigurare a calitatii,
– de adaptarea zilnica, prin intermediul Daily Scrum și
– nu în ultimul rând, responsabilitatea către ceilalți.
Product Owner
Și aici apar câteva diferente, deși poate cea mai interesantă ar fi chiar faptul ca PO nu mai este prima componenta a echipei Scrum descrisa în ghid (aceasta este Developers). Oricum, este interesant ca lista responsabilitatilor descrisa în mod specific este deschisă cu un element nou, și anume „Developing and explicitly communicating the Product Goal”. Revine acest Product Goal despre care am discutat și care aduce în prim plan interesul pentru obiectivul produsului, înaintea altor considerente.
Iarăși este interesantă formularea: „trying to convince the PO” fata de „must address the PO”, referitor la schimbarile din Product Backlog. Printre rânduri, ni se transmite ca aceasta schimbare trebuie să aibă niște argumente bine justificate, capabile de a convinge. In afara de asta, PO ramane cel care va lua decizia finala in privinta Product Backlog si schimbarilor din acesta.
Scrum Master
Prima schimbare care impune reflectie este cea de stil de leadership, care este denumita „true leaders” în loc de „servant – leader”. Nu știm dacă simpla utilizare a cuvântului „servant” s-a dorit a fi evitata (în contextul framantarilor sociale din SUA din ultimile luni), însă cred cu tarie ca autorii au lucrat la aceasta versiune mai de de mult decât in ultimile 9-10 luni.
Mai mult, Scrum Master-ul trebuie să fie un lider adevărat atât pentru echipa Scrum, cât și pentru întreaga organizatie. Este ca și cum autorii sugereaza ca Scrum Master-ul nu poate totuși funcționa și munci exclusiv pentru echipa Scrum ci și pentru intreaga organizatie performatoare.
Alte modificari relativ minore, dar de interes ar fi:
– în relația cu dezvoltatorii, se aduce în discuție ajutarea lor pentru a obtine produse de valoare, „care adera la Definition of Done”.
– în relația cu PO, se insista pe empirism privind product planning; Scrum Master-ul primeste o responsabilitate mai generica, de a ajuta PO sa gaseasca tehnici de definire mai eficace a Product Goal-ului si de management a Product Backlog (nu doar aranjare / prioritizare a acestuia). De asemeni, se schimba responsabilitatea de a facilita evenimente Scrum in responsabilitatea mai larga de a facilita colaborarea cu stakeholder-ii.
– în relația cu organizatia,creste importanta centrarii pe client / stakeholder, fapt intarit de urmatorul enunt de responsabilitate: „Removing barriers between stakeholders and Scrum Teams”.
Scrum Events
În descrierea evenimentelor Scrum revin în mod constant referintele la valoare (value), Sprint Goal și Product Goal. De exemplu, Sprintul este locul în care ideiile se transforma in valoare („where ideas are turned into value”); toată munca necesara pentru a atinge Product Goal are loc în Sprint. Este deci o aliniere și o orientare mai puternica a activitatatilor cu valoarea pe care acestea o genereaza.
Alte ajustari sunt legate de:
– incurajarea activitatii de refinement / grooming, ce are loc în timpul Sprint-ului, și la care se face referire în mod explicit (The Product Backlog is refined as needed);
– se re-afirma ideea de empiric și de inabilitate de a cunoaste / prezice lucrurile cu foarte mare acuratete. Practicile de forecast sunt declarate utile dar nu atot-clarificatoare;
– se revine la ideea de a utiliza inspectia și adaptarea, prezente în toate evenimentele Scrum, ca generatoare de predictibilitate în atingerea Product Goal și respectiv Sprint Goal, cu accent pe diminuarea pe cât posibil a duratei Sprintului;
– se diminueaza considerabil instructiunile legate de Sprint-urile anulate, având în vedere cat de rar ar trebui sa aibă loc acest fenomen și cât de neobisnuite ar trebuie să fie circumstantele în care are el loc; In 2020, ramane o singura fraza care arata in ce situatie si din a cui decizie se poate anula un Sprint.
– acțiunile de facilitator ale Scrum Master-ului in privinta Sprint planning sunt oarecum subintelese iar PO pare a fi vizat cu precadere (sa pregateasca informatii relevante, sa aduca stakeholder-ii potriviti); apare o noua referire la Product Goal in aceasta sectiune.
– o alta schimbare foarte interesantă este faptul ca cele doua topicuri ale Sprint Planning au devenit trei, din nou cu focus pe întrebarea „De ce este acest Sprint valoros / ce valoare aduce?”. Observam ca subcapitolul „Sprint Goal” din editia 2017 a devenit acum un pas concret al planificarii Sprintului; mai mult, este plasat de autori ca fiind primul pas ce trebuie parcurs în aceasta planificare. Apare aici si o definitie a Sprint Backlog-ului care este alcatuit din: Sprint Goal-ul, elementele din Product Backlog selectate pentru sprint si respectiv planul de a le livra.
– Definition of Done este adusă în discuție nu doar pentru a ști „cum” se vor face lucrurile, dar și „ce fel trebuie sa arate” incrementul, ce va fi realizat în acest sprint. De mentiona ca acest „ce fel trebuie sa arate” nu are nici o legatura cu munca ce trebuie realizata in sprint. Este o noua dovada ca acest concept (DoD) capata mai multă greutate în Scrum prin noul ghid.
– Daily Scrum aduce o alta schimbare interesantă, legată mai degrabă de continutul acestei întâlniri zilnice. Dacă în 2017 sunt oferite exemple – instrucțiuni mult mai detaliate, în 2020 autorii lasa la latitudinea echipei sa aleaga cea mai buna tehnica cu putinta „The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal ”. Practic, dispar cele 3 intrebari „celebre”, cu care foarte multa lume asocia notiunea de Scrum. Ele nu mai sunt oferite nici macar ca sugestii. Ghidul 2020 aduce insa clarificarea potrivit caruia Scrum Master-ul sau PO pot participa la acest eveniment doar dacă lucrează la elemente din Sprint Backlog.
– este adusa mai multa flexibilitate in ceea ce priveste comunicarea din cadrule echipei, pentru adaptare si re-planificare „The Daily Scrum is not the only time Developers are allowed to adjust their plan.”
– în Sprint review apare o noua fomulare interesantă, care arata ca Echipa Scrum și Stakeholder-ii revizuiesc împreuna ceea ce s-a schimbat în mediile lor (intern in cazul Scrum Team, extern in cazul stakeholders) pe parcursul acestui eveniment. Dacă în 2017 cele doua entitati lucrează împreuna în privința a ceea ce s-a făcut în acel Sprint, iată ca se acum se pune accent și pe ceea ce s-a schimbat, ce elemente au apărut sau au fost modificate și care au impactat / pot impacta munca. Dispar din acest capitol atât responsabilitatea Scrum Master-ului, cât și elementele pe care autorii le-au exemplificat în ghidul din 2017 ca făcând parte din acest eveniment.
– în Retrospectiva Scrum, ghidul 2020 ne aduce o condensare a informațiilor, cu aceeași relaxare privind cadrul de lucru sau exemplele concrete. Ca si la celelalte evenimente, dispar complet referirile la rolul Scrum Master-ului și cum acesta faciliteaza desfasurarea acestui eveniment. Esenta este mult condensata și spune în cuvinte puține ce anume se dorește „plan ways to increase quality and effectiveness” nu și cum trebuie să se întâmple asta. Pe de o parte se vede aici contributia primita de la Lean, si conceptul de „small improvments” & „continous improvment”. Pe de alta parte, se intareste autonomia echipelor de la self – organized catre self – managing.
Scrum Artifacts („Elementele tangibile” Scrum)
Descrierea generala a acestora vine cu un angajament interesant (commitments) intre cele trei elemente tangibile (Product Backlog, Sprint Backlog și Increment) și cele trei scopuri corespondente ale lor, care beneficiaza de transparenta și atentia (focus) lor (Product Goal, Sprint Goal și Definition of Done). Aceste trei elemente par a fi căpătat o prioritate interesantă în acest ghid și sunt regasite ca scop final în aproape toate capitolele noului ghid.
Descrierea Product Backlog este din nou una condensata și la obiect. Se precizeaza simplu și clar ca Product Backlog este unica sursa de munca pentru Echipa Scrum, fără a se mai da detaliile din 2017 privind continutul lui („lists all features, functions, requirements, enhancements, and fixes”) și faptul ca acest continut este unul viu, în permanenta modificare. Chiar și acțiunea de Product Backlog refinement, care în 2017 ocupa un paragraf întreg, acum este comprimata la maxim. A disparut si acea referinta la volumul de munca alocat (de 10%) pentru acesta activitate, care parea destul de restrictiva.
Subcapitolul Monitoring Progress Toward Goals din ghidul 2017, care ne prezenta unelte precum burndown charts, burnup charts sau cumulative flow este și el eliminat și înlocuit cu o expresie mai clara a angajatamentului pe care îl reprezintă Product Goal pentru Product Backlog. Se exprima clar ideea ca Product Goal-ul este în interiorul Product Backlog-ului, alături de alte elemente care vor îndeplini acel tel. Aici apare si definitia produsului (prima in Ghidul Scrum): „A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users or customers. A product could be a service, a physical product, or something more abstract.” Aceasta definitie vine in contextul legaturii dintre Product Backlog si Product Goal. Este ca și cum autorii încearcă sa accentueze ideea de empirism și sa propuna mai degrabă planificare către tel / obiectiv, decât planificari de resurse care sunt volatile în medii complexe.
Sprint Backlog vine cu precizari mult mai clare decât majoritatea conceptelor din noul ghid. Când vorbesc de componenta Sprint Backlog-ului, autorii precizeza clar un „de ce” (Sprint Goal), un „ce” (Set de items din Product backlog pentru Sprint) și un „cum” (planul pentru livrarea incrementului). Concret, Sprint Backlog e definit ca un plan conceput de developeri pentru developeri.
În mod similar ca la primul artefact, găsim un subcapitol („Monitoring Sprint Progress”) care este înlocuit de un altul („Commitment: Sprint Goal”). In 2017 se vorbește despre capacitatea echipei de a monitoriza munca ramasa și a o analiza în cadrul Daily Scrum, ceea ce trebuie sa arate progresul; în 2020, se discuta despre obiectiv și colaborare pentru a-l atinge sau pentru a-l ajusta prin negocierea ariei de cuprindere cu PO.
Cel de al treilea artefact, Incrementul, capata mai multă atenție în ghidul din 2020. Chiar și definitia sa evoluează de la „The increment is a step toward a vision or goal” la „a concrete stepping stone toward the Product Goal”. Așa cum spuneam anterior, nu se mai vorbește despre o ținta sau un obiectiv la modul general, ci despre Product Goal și modul în care Incrementul ajuta la atingerea lui. Evident ca Incrementul este în continuare utilizabil (usable) și atinge toate criteriile din Definition of Done. Elementul de noutate apare sub forma ideii ca pot exista mai multe incremente în cadrul unui Sprint și ca acestea ar putea fi livrate stakeholder-ilor fără a aștepta finalizarea Sprintului. Este deschisă astfel ușa către livrari foarte rapide, unele de la o zi la alta, sau de ce nu, de la o oră la alta.
Acest artefact primește și el un subcapitol referitor la angajamentul de transparenta, de data aceasta către „Definition of Done”. Acest concept devine foarte important, aproape ca un certificat de naștere pentru Increment („The moment a Product Backlog item meets the Definition of Done, an Increment is born”). Mai mult, sunt indicatii despre acele elemente din Product Backlog care, din moment ce nu au satisfăcut „Definition of Done”, nu trebuie nici măcar sa apara în Sprint Review. Sunt foarte interesante aceste instrucțiuni despre „Definition of Done”, într-un ghid care a eliminat / a considerat subintelese foarte multe din definitii și exemple practice prezentate anterior.
În concluzie
Simpla parcurgere a unei noi editii a acestui ghid este benefică, dar oarecum incompleta dacă nu este luata în contextul editiilor precedente. Dincolo de o simpla lectura, o analiza comparativa intre (cel putin) doua editii succesive ne provoaca sa fim mai atenți la sensul schimbarilor, la corectiile minore sau majore pe care cei doi autori simt nevoia sa le adauge în acest cadru de lucru.
Nu în ultimul rând, suntem atrași în a înțelege cât de bine s-a aplicat acest cadru de lucru în mediul real de lucru și în ce măsura feedback-ul recepționat din lumea managementului de proiect a adus după el ajustari explicate în clar de către autori.
