xebir logo mvp orizzontale psm1 small  cdacda consortium  safe sixsigma yellow belt mini  mcpd agileiot logo  ac2 logo

La dissonanza delle sfere di azione del valore

Nel precedente post abbiamo parlato del Fattore Canguro, ovvero del fatto che lo Scrum Master è spesso costretto a saltare da un’attività all’altra non potendo garantire l’impegno totale sul proprio ruolo, troppo spesso “non capito”.

Ma anche il Product Owner non vive sempre (o spesso, decidete voi J) momenti felici.

po

Questa cosa può decisamente stupire, visto che il ruolo del PO è ormai universalmente riconosciuto nel mondo agile, indipendentemente dal framework o dalla metodologia che si decide di utilizzare

Troppo spesso, però, il PO viene inquadrato al pari del Product Manager, o ancora peggio del Project Manager, ovvero il garante dei “tempi”: la sua attività primaria diventa quella di riportare al management di livello superiore l’andamento delle attività e preoccuparsi di “assegnare” le cose da fare. Se poi si utilizza un tool per la gestione digitale delle Storie, diventa colui che scrive le storie nel tool…

In tal modo si spoglia il PO della sua attività chiave che, come sappiamo, è quella di mantenere costante il focus sul Valore, supportando il proprio team e l’organizzazione nell’adattamento costante in relazione alle attese degli stakeholder e in funzione del contesto corrente.

po role

Una cosa ben diversa dal “dover guidare” il team nelle proprie decisioni, soprattutto se di carattere prettamente tecnico, appartenendo quest’ultime primariamente alla sfera di azione del team di sviluppo, con l’eventuale supporto di specialist e team esterni.

Ma allora, come rispondiamo a domande come:

  • Ma il PO stima le storie?
  • Il PO può dare suggerimenti tecnici?
  • Il PO può dire di “no” al management?
  • ….

Sono tutte domande che non hanno una risposta assoluta (se si esclude ovviamente quanto specificamente previsto dalla letteratura) ma dipendono, banalmente, dal contesto operativo di riferimento. Prendiamo la prima: se l’intero team ritiene che la stima del Product Owner abbia un “valore” per la Storia specifica, nonostante valga sempre la regola “stima chi fa il lavoro”, non c’è nessuna legge divina che impedisce al PO di effettuare la stima, dotandosi, ad esempio, di un planning poker deck esattamente come tutti gli altri. Non è una scelta che mi piace consigliare e adottare, ma in alcuni contesti può effettivamente aver senso.

Restano però imprescindibili i doveri del PO di accertarsi che quanto si stia realizzando ha un effettivo valore (per il committente così come per il service provider), così come è suo diritto/dovere apportare tutte le modifiche che ritiene opportuno al Product Backlog, possibilmente sempre in maniera collaborativa.

Chiudiamo sottolineando che nche per il PO valgono le stesse identiche considerazioni fatte per lo Scrum Master rispetto alla distinzione “ruolo/posizione”: bisogna avere un ingaggio a tempo pieno sul ruolo per consentire alla Persona di coprirne i diversi aspetti e poter migliorare costantemente nelle proprie attività.

Stay tuned J