carti

Schimbarea priorităților și agilitatea

În urmă cu o săptămână am început să citesc o carte despre care am aflat că era atât interesantă cât și amuzantă fără a fi, însă, un pamflet. Am și scris pe pagina mea de facebook care este această carte și motivul pentru care am ales-o.

După două zile a sosit un colet de cărți comandate cu ceva timp în urmă și printre ele câteva cărți legate de Agilitate și Lean, subiecte care în perioada aceasta sunt prioritare pentru mine, întrucât voi participa la Codecamp Iași ca și speaker.

Așadar, odată stabilite prioritățile, întrebarea este dacă alegerea înțeleaptă este să continui cu cartea începută deja sau să o las deoparte și să încep una pe tema prioritară.

Pentru a putea răspunde, sunt câteva lucruri de stabilit:

  •      Cât de mult am parcurs din cartea deja începută și cât preconizez că va mai dura până finalizez această carte? Acest aspect este important pentru a stabili cât de mult mă “va costa” reluarea cărții mai târziu.  Orice muncă începută și neterminată va genera un cost (timp, energie) atunci când o reiei.
  •      Cât de prioritară este tema Agilitate/Lean pentru mine?
  •      Dacă această temă este într-adevăr prioritară, cât de urgentă este parcurgerea unei cărți din tema agilitate/lean și care este impactul dacă amân lectura/studiul la una din celelalte cărți?

Răspunsul la aceste întrebări mă ajută să fac o alegere pe care să mi-o asum și pe care să o pot explica (mie în primul rând).

 

Concluzii

De multe ori, atunci când lucrez cu echipe pentru a deveni agile, membrii acestora se supără când Product Ownerul schimbă prioritățile (mai ales în timpul Sprintului), pentru că teoria spune că în timpul unui Sprint nu se shimbă cerințele (User Story-urile) intrate. Chiar am îbtâlnit cazuri în care membrii echipei catalogau asta ca fiind haos.

Într-una din extreme auzim acest argument din partea echipei, ceea ce duce la frustrări mari atunci când acest lucru nu se întâmplă.

La cealaltă extremă, auzim opinia celor din management sau al Product Ownerului care spune că e normal să schimbe des prioritățile, pentru că asta înseamnă să fii agil.

 

Exact ca în viața reală, însă, întrebările pe care e important să le adresăm sunt:

    •  Cât de urgent/prioritară este noua cerință?
    •  Dacă ne ocupăm de această cerință, pe care o lăsăm deoparte? Cât de avansați suntem/cât efort am depus în implementarea acesteia?

 

Cât de des se întâmplă ca prioritățile să fie schimbate?  Schimbările acestea au loc pentru că:

  •     Product Ownerul nu comunică/nu înțelege încă ce are nevoie clientul. În acest caz e important ca Product Ownerul să petreacă mai mult timp cu clientul, să înțeleagă nevoile lui și totodată cerințele care decurg de aici.

sau

  •  Clientul final își schimbă opinia? În acest caz, ar fi o soluție reîntoarcerea la scopul inițial, la viziunea a ceea ce vrem să contruim, la o discuție mai profundă cu clientul/stakeholderii?

Nu există o regulă care să spună că nu putem schimba nimic, asta ar încălca însăși definiția agilității, care ne îndeamnă să analizăm la fiecare pas ce e mai important pentru client să facem și să reducem cantitatea de muncă ce nu aduce beneficii.

Nu există un răspuns universal pentru situația descrisă mai sus,  însă consider că abordarea cea mai potrivită este cea pe care o aplicăm  în viața de zi cu zi.

Răspunsul la întrebările de mai sus conduc partenerii către o conversație în urma căreia se ia decizia cea mai bună în contextul dat și se poate redefini cadrul în care acești parteneri își doresc să lucreze pe mai departe.

Dacă aceste discuții nu vin în mod natural și pentru a menține tonul constructiv al conversației, Scrum Masterul echipei este de mare ajutor.

 

Eu personal, de această dată am decis să las deoparte cartea inițială și să încep una din cele primite în colet.

 

 

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>