Archivi categoria: ALM

L’Ombra Ingombrante del Budget Previsionale

Facebooktwittergoogle_plusredditlinkedin

Quando andiamo a parlare di DevOps “nobile”, ovvero di Lean e del rapporto stretto al Value Stream inteso come la capacità di soddisfare continuamente il cliente con soluzioni consumabili, ci si scontra operativamente con un aspetto di non facile risoluzione: come gestire il budget?

Si tratta di una questione molto articolata e fortemente relazionata all’ambiente di riferimento, ma sicuramente caratterizzata da un concetto fondamentale: il budget non dovrebbe essere un budget di progetto, ma dovrebbe essere associato proprio al value stream.

Questo contribuisce a considerarlo come uno strumento a supporto dell’iniziativa, che deve, quindi, essere in qualche modo dinamicorelazionato alle evidenzeper poter accompagnare l’evoluzione stessa dello stream di valore in funzione di quanto realmente riscontrato. Non deve quindi essere un budget previsionale che “vincola”, piuttosto uno strumento riadattabile che fa propri i valori stessi di Agile ed i principi di Lean.

piggyshadow

Ad intuito dovrebbe essere già evidente come in un mondo complesso è veramente illusorio pensare di poter allocare un budget rigido e pretendere al contempo di definire e derivare puntualmente tutto il resto. Ma se l’intuito non fosse sufficiente, a suffragare questo sentore si trovano anche diversi studi e ricerche (fatti coinvolgendo i CFO e le prime linee interessate) che mostrano come quasi il 90% delle strutture relative non sono soddisfatte degli strumenti e degli approcci attuali al budgeting, mentre più della metà evidenzia come sia sempre più difficile relazionare il budget con gli obiettivi strategici perseguiti e raggiunti.

Essendo il budget estremamente vincolate (e spesso penalizzate), non deve meravigliare come questo aspetto rientri a pieno titolo in quelli interessanti da un’azienda che intraprende il cammino dell’Enterprise Agility e come framework quali SAFeDAcontemplino esplicitamente, seppur con un approccio diverso coerentemente con le relative specificità, tale aspetto, parlando, rispettivamente, di Lean BudgetsFinance.

Senza però doverci legare obbligatoriamente ad un framework di scaling, esistono diversi approcci che provano a sposare una filosofia di “Continuous Budgeting”, tra cui il più popolare è probabilmente Beyond Budgeting, basato su 6 principi e 6 pratiche fondamentali.

beyound budgeting

È interessante notare che, implicitamente, si mette ancora una volta in evidenza come LeadershipManagementsiano due facce della stessa medaglia che possono e devono convivere nell’azione organizzativa.

In generale, questo insieme di principi e pratiche consente di abbattere la rigidità della pianificazione tradizionale, focalizzandosi sull’obiettivo e non sul costo ipotizzato, per l’iniziativa o progetto che sia. Risulta evidente come la capacità di rivedere costantemente il budget impatti in modo diretto sul “contenuto” dell’iniziativa, aumentando l’efficacia e l’importanza di avere un backlog dinamico che consenta di modificarne lo scope, non solo in relazione alle nuove esigenze degli stakeholder, ma anche all’eventuale erosione imprevista delle risorse finanziare disponibili.

Stay tuned J

La burocrazia dei requisiti diluita nella Pila

Facebooktwittergoogle_plusredditlinkedin

Il Product Backlogè molto spesso l’elemento centrale da cui si sviluppano le diverse attività di un team Agile, siano esse di envisioning, pianificazione o relative al lavoro giornaliero.

Si tratta, per quanti non ne avessero dimestichezza, di un elenco verticale delle attività da realizzare, ordinate secondo diversi criteri (il più utilizzato è genericamente per Valore) dall’alto verso il basso: una sorta di pila che contiene tutto quanto necessario realizzare per completare il prodotto.

Ma è davvero così semplice creare un Product Backlog, capire cosa inserirvi e gestirlo adeguatamente in modo che sia anche un “manufatto live” che sostituisca in tutto e per tutto la burocrazia dei requisiti? La risposta è chiaramente no, e le sperimentazioni sulle diverse forme che il Product Backlog può assumere sono continue e spesso fonti di nuove domande.

pbacklog extended

Si pensi ad esempio all’interpretazione del Product Backlog in chiave Disciplined Agile in cui lo stesso deve soddisfare la necessità di creare una “Soluzione Consumabile” e non “Software funzionate”: questo implica che in esso troveremo non solo le iniziative di sviluppo, ma anche tutte le attività aggiuntive (se continuiamo a considerare Core lo sviluppo) che sono necessarie per rendere “consumabile” quel prodotto da parte degli utenti finale. Un esempio per tutti: la creazione del manuale utente.

Inoltre, esiste sempre più la tendenza di non vincolarsi strettamente a forme canoniche per la descrizione delle attività, come ad esempio le User Story(funzionalità orientate all’utente), ma contemplare anche elementi che in qualche modo l’utente non può toccare in modo diretto se non nel complesso del prodotto in quanto sua componente fondamentale. Ad esempio: se si crea un nuovo prodotto da zero, i servizi trasversali come logging security come li esprimo nel backlog? Che priorità hanno? Li lego ad una storia utente, oppure li esplicito per abbracciare i principi di chiarezza e trasparenza insiti nel backlog stesso? Io, generalmente opto per quest’ultima soluzione, lavorando con il PO per trovare la forma corretta di comunicazione relativa con il cliente.

Se andiamo in ottica DevOps (Lean), il Product Backlog non dovrebbe essere più considerato solo espressione del team di sviluppo, ma si dovrebbe guardare il quadro complessivo e includere, quantomeno, le attività annesse al deploy delle funzionalità realizzate. Anche qui un esempio: il product backlog dovrebbe contenere l’attività di creazione degli script per il provisioning delle macchine necessarie all’erogazione dei servizi, fondamentali per supportare fin da subito le attività di testing così come quelle di consolidamento delle pipeline di rilascio.

Anche sulla questione prioritizzazione c’è molto da lavorare: l’ordinamento per Valore utente, per quanto il concetto di Valore non sia di per sé univoco, può diventare semplicistico, non tenendo in conto, ad esempio, la necessità di esplorare tecnicamente alcune caratteristiche che possono rappresentare un forte rischio per il successo dell’iniziativa stessa. In generale è sempre utile avere almeno un ordinamento che si basa sul dualismo Valore-Rischio (value-risk driven) in modo da bilanciare due obiettivi: avere nuovi elementi di cui discutere con l’utente e diminuire il rischio intrinseco di quanto si sta realizzando, aumentandone la confidenza e spostandosi a destra lungo il Cono di Incertezza.

cone of uncertainty

Nella concezione qui evidenziata, il Product Backlog diventa quindi un contenitore live che, rispettando gli specifici criteri di ordinamento, consente di avere costantemente una fotografia di tutto quanto necessario per portare a termine l’iniziativa, evidenziando al contempo le specifiche ownership dei work center (DevOps/Lean) e le possibili criticità, in modo da intervenire prontamente per risolvere.

È sempre interessante sottolineare come dietro uno strumento apparentemente semplice, si celi una “cultura dell’utilizzo” che può essere coltivata solo in seno al team specifico e all’organizzazione di appartenenza, non dimenticando anche le caratteristiche proprie del prodotto che rappresenta.

Stay tuned J

Dalle Stelle alla Sfera Celeste

Facebooktwittergoogle_plusredditlinkedin

Molte delle azioni che si mettono in campo per intraprendere la strada dell’agilità riguardano i team, andando a lavorare su Teamcon la “T” maiuscola, intesi come una cellulain grado di adattarsi e riconfigurarsi per creare Valore.

Questo aspetto è specificamente formalizzato in Lean, relativamente al JIT Pillar, e identificato come Cellular Manufacturing, con l’obiettivo di aumentare la produttività, riducendo il Lead Time grazie alla semplificazione della programmazione, al controllo produzione e alla riduzione delle scorte. Il tutto è reso possibile dalla spinta sulla comunicazionee sul coordinamento.

cellular manufactoring

L’aspetto fondamentale è che il Team lavora su un’attività specifica e lo fa al meglio, tendenzialmente inseguendo lo stato dell’arte, coordinandosi con le cellule a monte e a valle per garantire un flusso costante e sostenibile.

Ma cosa succede se il team è un teamcon la “t” minuscola, ovvero un insieme di Persone che sono sedute vicine, a stento si parlano e che sono impegnati su più progetti contemporaneamente, anche gestendoli in modo esclusivo?

Si tratta di una condizione più comune di quanto si pensi, che rende arduo attuare una trasformazione Agile/Lean (o DevOps), e che non tiene conto di principi ormai universalmente riconosciuti come il costo di uno switch continuoe un ritmo di lavoro sostenibile(entrambi MUDA).

Difficile in queste condizioni, ad esempio, pensare a Scrum, perché: che senso ha fare Scrum se le attività (parlare di Product Backlog in tal caso è un eufemismo!) sono in carico ad una sola persona? Come farebbe il Daily… guardandosi allo specchio?

Scherzi a parte, in alcuni casi è più utile immaginare un percorso progressivo che permetta di inserire elementi di ottimizzazione e cominciare a porre le basi di una cultura orientata alla comunicazione e alla gestione sostenibile delle attività.

Di base può balzare in mente un approccio Kanban-like, ma non bisogna dimenticare che operare in tal modo richiede una forte maturità per non “lasciare indietro” aspetti fondamentali (si pensi al fatto di non fare la retrospettiva perché non si ha tempo), motivo per cui approcci di questo tipo spesso si utilizzano nello scaling… ma qui possiamo avere un problema: posso immaginare di usare Kanban come base e poi “scalare” a qualcosa più simile a Scrum quando aggrego più persone? Ha senso?

Per provare a immaginare un approccio che possa comunque supportare anche gruppi di 2 persone, guardando ad una dinamicità guidata dallo stream di attività legate ad un cliente, stiamo sperimentando quello che ha preso il nome di AgileConstellatione che trovate all’indirizzo agileconstellation.org

celestialsphere bigpicture

Siamo curiosi di avere i vostri feedback, suggerimenti o altro.

Stay tuned J

La congiunzione astrale dell’indipendenza del Verbo

Facebooktwittergoogle_plusredditlinkedin

Qualsiasi trasformazione richiede tre elementi fondamentali: tempobudgetsponsorship. Questo è un dato di fatto a prova di smentita, tant’è che il venir meno di uno di essi compromette fortemente, se non inesorabilmente, le possibilità di successo dell’azione intrapresa.

In particolare, è necessario riflettere molto sulla sponsorshipe capire se essa sia reale opportunistica:

  • la sponsorship è realequando gli sponsor sono i primi ad essere coinvolti nell’azione di trasformazione, calandosu di sé quando si sta sperimentando e accettandodi rimettersi in gioco, consci che il tutto possa portare un reale beneficio all’intera organizzazione. Bisogna essere convinti della necessità del cambiamento, unitamente ad una buona dose di umiltà e capacità di guardarsi intorno per capire se il percorso intrapreso sta portando benefici;
  • la sponsorship è opportunisticaquando non è minimamente sentita, ovvero quando si supporta un cambiamento solo perché “qualcuno lo ho detto o perché tutti lo fanno”. In tal caso si cerca di piegare la stessa ai propri interessi, intervenendo fortemente nelle diverse azioni al fine di plasmarle secondo le proprie necessità e mantenere la propria confort zone, eventualmente appuntandosi una nuova “etichetta” che però non modifica la sostanza. 

Come diceva Tancredi ne “Il Gattopardo”: Se vogliamo che tutto rimanga come è, bisogna che tutto cambi… e quindi bisogna fare molta molta attenzione nel rispondere rapidamente alla condizione che ci vede difronte ad una sponsorship opportunistica. 

lampedusa gattopardo

Purtroppo, è molto difficile riuscire inizialmente ad indentificare la specificità: solo il tempo ci da la possibilità di captarecapireed analizzarei segnali ed i fatti che possono portarci ad avere un’idea in merito. 

Un elemento che però è fortemente indicativo è l’Indipendenza degli Agenti di Trasformazione (o dei Coach se siete in chiave Agile), che devono potersi muovere calando sulle evidenze le azioni che ritengono più consone, dando messaggi chiari che evidenzino sempre quale sia l’obiettivo ideale e quali, invece, sono i compromessi da accettare per cominciare ad innescare il cambiamento e generare miglioramenti.

Guai se i messaggi sono “tarati” sui desideri dello sponsor: in questo caso non stiamo solo dicendo addio al nostro “viaggio”, ma anche alla credibilità stessa dell’approccio che stiamo proponendo. Nessun commento superfluo è ovviamente utile per definire chi si presta a tale azione.

Se si verifica una congiuntura astraleche allinea tutti questi elementi, il risultato ultimo si sintetizza con una frase che purtroppo si sente non di rado: “Agile non funziona!”che di per sé è priva di significato essendo Agile un mindset formato da Valori e Principi e non da processi che invece vanno contestualizzati… …nel modo giusto.

Stay tuned J

La frizione implosiva del connettore sdoppiato

Facebooktwittergoogle_plusredditlinkedin

Non di rado si assiste alla creazione di un ruolo aggiuntivo nei team Agili che si imbarcano nel lungo e tortuoso cammino della propria evoluzione: si tratta del Team Leader.

Come sappiamo, Scrum, non contempla questa figura specifica, mentre, ad esempio, in Disciplined Agile Delivery è contemplato il ruolo di Team Lead, inteso come colui che supporta il team nella crescita organizzativa e che può assumere anche alcune connotazioni tecniche a supporto (spesso, nei piccoli contesti, il Team Lead è anche l’Architecture Owner).

 

dad roles

DAD Roles

Se si istituisce il ruolo di Team Leader, il focus di chi lo impersona (attenzione alla solita questione ruolovs posizione) è quello di supportare la crescita del teamin chiave Servant Leader, sia in ambito organizzativo che in ambito tecnico.

Operando in quest’ottica, l’approccio permette di creare una figura chiave che diventa un connettoredel team con le diverse interfacce aziendali, andando effettivamente ad accelerare la crescita dell’autonomia del singolo team e creando un ecosistema in grado di operare secondo i più nobili principi agili.

Esistono però tutta una serie di rischi relativi: primo tra tutti, il Team Leader non deve diventare il “capo” del team che dice agli altri cosa fare. Purtroppo, si tratta di una deriva spesso comune, sorretta anche dalla difficoltà dell’organizzazione stessa nell’inquadrare correttamente il ruolo. Se si torna ad operare in chiave command-and-control, il team agile smette semplicemente di esistere, trasformandosi in un insieme di persone a cui vengono assegnate attività che sono definite, decise e strutturate da qualcun altro.

Inoltre, il Team Leader non riesce a “coltivare” la crescita del team, trasformandosi a sua volta in una sorta di “controllore” e “passa carte”, ovvero uno strumento di un’organizzazione strettamente piramidale.

Certo, è possibile avere due figure separate, una per il “Team Leader” e l’altra per Scrum Master/Coach, all’interno di un singolo team, ammesso che questo sia economicamente sostenibile. Il rischio è quello di creare due figure “lead” per il team, generando confusione e anche frizione:chi è più qualificato nel prendere decisioniChi risponde ai quesiti?Chi dirime le controversie tra i due? Insomma, la cosa può funzionare, ma richiede una forte maturità e la capacità personale di capire il proprio perimetro operativo.

InterruptionCop

Nel caso in cui il tutto resti estremamente nebbioso, il rischio è che il team cominci a procedere in modo indipendente, ovvero prendendo decisioni localiper ottenere quanto possibile, senza però preoccuparsi del perché delle cose e, soprattutto, rendendo di fatto il ruolo del Team Lead una sorta di “guscio vuoto”.

Si crea così una spirale implosivache porta ad una rottura di fiducia tra il Lead e il team (eventualmente anche con lo Scrum Master ed il Coach) che a sua volta si trasforma in frustrazione e incapacità di produrre miglioramenti sui diversi fronti. 

In generale, il Team Leader non deve necessariamente essere il “più bravo”, ma deve essere una persona capace di ispirare gli altri e mettersi al servizio del team e dell’organizzazione per generare valore, gestendo rapidamente i rischi, attivando quanto e chi necessario per risolvere gli impediment e celebrando i successi del team.

Il suggerimento è sempre quello di individuare persone che abbiano una spiccata capacità di “guardare agli altri”, con forte esperienza in ambito Agile e che abbia maturato competenze tecniche a differenti livelli tanto da porre la tecnologia a servizio del Business e non piegare quest’ultima in funzione della prima.

E ricordate: si tratta di un ruolo, per cui se la persona candidata/scelta non si trova a suo agio o non è accettata dal team… si può sempre cambiare!

 

Stay tuned J

Il panorama nebbioso della terminologia ambigua

Facebooktwittergoogle_plusredditlinkedin

DevOps oppure Agile? Ma sono la stessa cosa? Che c’entra Lean?… il nostro mondo è un mondo che sembra amare la confusione, fattore che, unito alla complessità tipica dei problemi affrontati, porta ad un panorama nebbioso che sembra non diradarsi mai.

La tendenza è ormai ventennale, tant’è che gli stessi autori di Scrum utilizzano spesso la Teoria dei Giochi per descrivere il proprio framework, mettendone in evidenza i principi di equilibrio e muto interesse. Tutto bello, ma possibile che non riusciamo a trovare un modo sintetico per raccontarlo a chi vuole andare diritto al sodo?

Stesso problema per Deploy e Delivery: cosa li differenzia? Da un lato, fino a qualche anno fa, si parlava di Deploy per indicare il rilascio fino agli ambienti di pre-produzione, mentre la Delivery era il rilascio finale in produzione. Ok, ma in fondo cosa cambia da un punto di vista tecnico? Probabilmente ben poco e se si automatizza l’ultimo miglio (dalla Continuous Integration al Deployment in produzione) tendenzialmente niente.

Ecco che quindi oggi, con l’ascesa di DevOps, il Delivery viene ricondotto al più nobile significato contemplato in Lean, ovvero la produzione continua di Valore per il cliente…. interessante, ma… un attimo… ricordiamoci del primo principio dell’Agile:

La nostra massima priorità è soddisfare il cliente rilasciando software di valore, fin da subito e in maniera continua”

hmmm… praticamente dice la stessa cosa…siamo di nuovo punto e a capo!

Anche le pratiche che vengono definite di DevOps sono riconducibili all’Agile: si pensi alla Continuous Integration, Pratica di Extreme Programming.

Provando a cercare qualche suggerimento in letteratura, un post di Sakshi Gaurav propone una interessante lettura di DevOps rispetto all’Agile, secondo la quale:

            “DevOps è una pratica, laddove Agile è un Processo”

presentando un’infografica che mette a confronto le due affermazioni.

devops to agile infographics

Ora, per quanto è vero che, comunemente, Agile viene associato agli aspetti di sviluppo, mentre DevOps a quelli di rilascio, se si legge il tutto in chiave Lean, dove è importante ragionare in termini di Value Stream e di organizzazione complessiva e non locale, qualcosa sembra non tornare in questo… e anche i framework di Scaling mixano il tutto.
Quindi DevOps non può essere ricondotto solo a “pratiche e tool”, ma ad una visione complessiva che coinvolge anche team terzi (differenti da Dev e Ops) ma comunque funzionali alla creazione di una Soluzione Consumabile, così come enfatizzato da Disciplined DevOps.

La definizione che spesso mi piace utilizzare è che “DevOps è la declinazione più efficace di Lean applicato al mondo del Software”, una sorta di Lean Software Development 2.0, in cui i tool hanno un forte impatto perché ormai maturi a supportare l’automazione dell’ultimo miglio ma il tutto è sempre funzionale ad obiettivi di business. Si parla quindi di Work Center e, in quest’ottica, Dev e Ops sono il fulcro delle attività, con Dev che utilizza gli approcci Agili ben consolidati, estendendoli ad Ops, e Ops che si occupa di creare l’infrastruttura a supporto per il deployment (fino in produzione) e garantire l’affidabilità dei servizi, condividendoli con Dev.

Se poi vogliamo completare il discorso… beh… un po’ di Design Thinking può esserci di aiuto per la fase di Inception e per tirare giù nuove idee e Lean StartUp per validarle velocemente rispetto ai potenziali clienti… ma di questo parleremo prossimamente.

Stay tuned J

La metafora del Mappazzone

Facebooktwittergoogle_plusredditlinkedin

Ebbene lo ammetto! Spesso mi diverto a guardare la nota trasmissione televisiva masterchef, non tanto per la gara in sé (a malapena so cucinare un piatto di pasta con il sugo pronto), ma per la capacità dei giudici di creare un’atmosfera che coniuga il momento gioviali all’interno di attività che richiedono forte concentrazione, preparazione e precisione.

In realtà, in masterchef troviamo molti elementi comuni del mondo Agile: timeboxed, capacità di adattamento (es: mistery box), l’importanza fondamentale di lavorare in team (brigate), l’obiettivo ultimo di soddisfare sempre l’utente (i giudici).

Potremmo, probabilmente, immaginare addirittura qualcosa di simile ad un’Agile Masterchef workshop.. e non è detto che prima o poi non lo faremo J

Quello su cui però voglio soffermarmi è un termine, preso in prestito proprio dalla trasmissione in oggetto, che mi è capitato spesso di utilizzare ultimamente nell’azione di coaching, soprattutto quando affrontiamo questioni tecniche inerenti al design applicativo: il mappazzone!

Il termine è usato dallo chef Bruno Barbieri e, come lui lo usa per descrivere un piatto che non ha anima, ma che è semplicemente l’insieme caotico di ingredienti mischiati alla meglio, così lo si può utilizzare per descrivere un cattivo design applicativo.

barbieri mappazzone

Ma cos’è un cattivo design applicativo? E ci mancherebbe altro che, da Coach, non rispondessi “dipende” J, anche se abbiamo a disposizione diverse linee guida: dai principi SOLID, a GRASP e quindi ai Design Pattern e ai concetti di Separation of Concern.

Per scoprire se quanto stiamo realizzando si sta trasformando in un mappazzone, suggerisco spesso ai team di sfruttare approcci come TDD o, se preferiscono qualcosa di meno stringente, Test First Programming, e farsi una semplice domanda: il codice è facile da testare? Riesco a creare uno o più test che mi verificano quanto realizzato in chiave end-to-end?

Ecco, se la risposta a queste domande è tendenzialmente no, stiamo creando un mappazzone!

È sempre interessante riuscire a parlare con i team in modo diretto, trovando formule di uso comune che, con semplicità, apra una riflessione e porti a delle azioni di miglioramento… a mio avviso, un bravo coach si riconosce spesso dalla capacità di sintesi, ovvero di riuscire a esprimere in con poche parole o metafore, concetti complessi, portando il team a farsi delle domande e cercare delle risposte… un po’ alla Lubrano.

Stay tuned J

La dissonanza delle sfere di azioni del valore

Facebooktwittergoogle_plusredditlinkedin

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