by Citeam ieri un articol din sfera managementului de produs, despre dificultatile Product Managerilor in lucrul cu echipele Agile de dezvoltare software.
Premisele de la care plecau autorii m-au intristat: Product Managerii sunt frustrati de lipsa “commitment-ului” dezvoltatorilor iar acestia se plang de schimbarile de directie si lipsa vederii in perspectiva a directiei produsului. Si m-au intristat in primul rand pentru ca partial le-am recunoscut.
Concluziile finale ale articolului subliniau patru directii pentru evitarea/repararea problemei:
- Construiti o relatie de incredere
- Comunicati viziunea
- Clarificati rolurile
- Prioritizati munca
Sunt toate action-items adresate aparent Product Managerului (Product Owner-ului unei structuri Scrum). Cu siguranta autorii articolului doar lor li se adresau. Si aici mi se pare ca greseau.
Hai sa aruncam mai atent o privire asupra acestor probleme si din perspectiva ScrumMaster-ului
Relatia (de incredere) se construieste intre doua parti, asa ca Product Owner-ul nu o poate construi singur. Ca si lider informal al echipei, ScrumMaster-ul da tonul – reactia lui, atitudinea, deschiderea de a comunica cu oamenii de produs, pe care echipa le observa la el, se propaga. La fel si lipsa lor.
Comunicarea viziunii – in mod clar o cerinta pentru Product Owner. Cu toate astea ScrumMaster-ul e cel care petrece cea mai mare parte a timpului cu echipa. In acelasi timp are informatiile despre viziune sau directia produsului cu un pas inaintea celorlati membri ai echipei. Cu siguranta le poate raspandi mult mai usor decat Product Owner-ul care poate aloca un timp limitat raspandirii lor.scrum master
Clarificarea rolurilor – membri ai echipei, de-specializati-va!, pare sa spuna Agile. Cu toate astea lipsa unor specializari in cadrul echipei, designer, admini de sistem sau baze de date, creeaza impedimente.Cine trebuie sa semnaleze si sa escaladeze lipsa lor pentru a rezolva impedimentele? ScrumMasterul.
Prioritizati munca! OK, aici m-ati convins. E clar treaba de PO, nu? :). Da, dar pe termen lung, la nivelul release-urilor. Pe cand, zilnic, cine inspecteaza statusul Sprintului curent, adapteaza prioritatile impreuna cu echipa, pentru a putea atinge scopul final al iteratiei?
Doar ca sa stiti, ScrumMasteri, faceti mai mult decat credeati!
Interesant articolul.
Si eu sunt de parere ca PO nu e singur, dar ca primele 2 probleme apartin de PO/PgM (daca PO nu comunica clar si nu se tine de cuvant pe parcursul unui SPRINT, isi poate pierde increderea) si ultimele doua de Scrum Master pentru ca tin mai mult de ce se intampla inside Sprint intr-un release.
Cu toate acestea si eu am vazut ca in general problemele sunt cauzate din pricina… PO-ului 🙂 din simplu motiv al Comunicarii si nimic mai mult. De multe ori nu comunica clar viziunea si nu se consulta de fiecare data cu SM-ul. Si cred ca la asta au vrut sa faca referinta cei cu articolul initial, dar au cam incurcat atributiile dupa cum bine ai subliniat:)
Multumesc Bogdan, pentru comment! Totul pleaca de la cum pot colabora cei doi si cat de compatibili sunt pentru a actiona impreuna pe cele 4 directii.
Zic ca SM-ul are mai mult timp la dispozitie cu echipa dar si suficienta vizibilitate spre produs incat sa compenseze cateodata lipsa de timp a PO.
Relatia de incredere trebuie sa plece de la ei doi. Si cand se intampla asta, lucrurile functioneaza!
Cat despre vina, nimeni nu e complet inocent 🙂