Archive for Uncategorized

Si può misurare la produttività (anche se non produciamo spilli)?

Se producessimo spilli sarebbe senza dubbio più semplice: oggi facciamo 10mila spilli al giorno, ottimizzando i processi e migliorando la catena produttiva il prossimo anno potrei produrne 30mila al giorno.
Poi un giorno inizierei a chiedermi: sono sicuri che valga la pena lavorare ancora sugli spilli? e non forse produrre linguette adesive che non forano il tessuto?
Allora inizierei a produrre le linguette, ma ecco che se volessi fare un mero conto della serva e monitorare la capacità produttiva della mia fabbrichetta non potrei certo confrontare l’anno 2 (quando producevamo spilli) con l’anno 3 (quando una parte inizia a produrre linguette, con un processo industriale totalmente diverso che mi porta inizialmente a produrne 5000 al giorno). E l’anno 4? ancora diverso, le linguette vanno a ruba e parte della produzione si sposta su quello ma una parte di clienti ha ancora bisogno di spilli, e il 30% della produzione resta ancorata a questo prodotto legacy.

Questo semplice esempio dimostra che misurare la produttività non è semplice nemmeno per chi produce spilli, in realtà.

Ma se un importante stakeholder ti chiede un giorno di definire un KPI per misurare come cambia la produttività del team, sicuramente un po’ di fatica mentale ci deve essere dedicata.
Abbiamo affrontato l’argomento in una community of practice interna, dedicata alla metodologia: un gruppo di product owners e scrum masters che inizia a buttare giù qualche idea ricordando che, per definizione, un indicatore di performance (KPI) deve essere SMART
Specifico, come motivazione di business che vuole misurare
Misurabile, per fornire un vero valore oggettivo
Achievable (raggiungibile) altrimenti si chiama utopia
Rilevante per l’azienda, altrimenti misura
Time oriented, cioè definibile in un intervallo di tempo.

Inoltre, misurando la produttività del team e non dell’intera azienda, non può posizionarsi troppo lontano nel processo aziendale per non rischiare di essere influenzato da variabili esterne su cui il team non ha controllo: quindi niente misuratori di ricavi o risparmi.

La conclusione (parziale) non è stata esaltante: esistono tali e tante variabili che sembra quasi impossibile monitorare la produttività.
Un paio di idee abbastanza interessanti, per lo meno come spunti di riflessione, sono state le seguenti.

Misuratore del tempo produttivo.
Risponde alla domanda: quanto tempo impiega il team su attività che portano un effettivo deliverable?
Abbiamo ipotizzato un rapporto: tempo totale impiegato sulle attività di sprint (e registrato in Jira, il nostro project management tool) DIVISO il tempo totale lavorato in uno sprint.
La parte restante di questa percentuale è attività non meglio precisata, attività reattiva (supporto, bug fixing), meeting e cerimonie, richieste non in sprint etc.
Il limite principale sta nella capacità che hai il team di loggare con precisione e onestà i tempi lavorati in sprint.

Misuratore di capacità di erogare deliverable
Risponde alla domanda: quanto prodotto è capace di erogare un team?
Abbiamo assunto che su lunghi intervalli di tempo la dimensione delle user stories fosse sufficientemente omogenea e di conseguenza il valore (in termini non economici ma di quantità di servizio erogato) fosse ben confinato all’interno dei limiti di una storia: quindi numero di storie erogate in uno sprint DIVISO il numero di team member, allo scopo di normalizzare questo parametro in funzione delle naturali variazioni di un team nel tempo.

Per adesso, comunque, la decisione condivisa co lo stakeholder è stata di abbandonare questo tentativo; la messa a punto di queste misure è troppo onerosa e il risultato tutt’altro che garantito.

Per ora, la risposta alla domanda nel titolo è: NO.

Product Owner vs Project Manager

productowner_vs Mi scrive un responsabile marketing criticando il testo di una email. Il testo esprimeva perfettamente i concetti che volevo comunicare e la visione con cui ho pensato questa campagna marketing era perfettamente descritta dalla email che il team (nella persona del content designer) aveva creato. Quella che non era piaciuta era la forma, le espressioni usate, le singole parole.
Qualche giorno prima e in maniera analoga mi era stata contestato il colore di uno sfondo.
La mia posizione in questi casi è un po’ imbarazzante perché a una prima osservazioni sa molto di allontanamento delle responsabilità; infatti in questi casi sono costretto a ricordare che il Product Owner si occupa esclusivamente di cosa viene sviluppato e su questo ha totale autonomia di scelta ma, una volta fissati i criteri di accettazione della storia (acceptance criteria) e i criteri generali di accettazione di un rilascio (definition of done e non functional requirements), non osa mai spingersi nella valutazione (tanto meno nella validazione) del come una cosa viene fatta, dando per scontato uno dei principi fondamentali dello Scrum: l’intelligenza collettiva di un team che rilascia una feature è superiore all’intelligenza di una singola persona, fosse anche il Product Owner.
Che sia vero o falso è poco rilevante, questa è la regola del gioco dello Scrum che io ho accettato in tutti i suoi aspetti, cambiando di fatto la mia professionalità da Project Manager a Product Owner. Rispetto al passato ho perso senza dubbio tanta decisionalità sulla qualità e sul modo di esecuzione, avendo però acquisito un margine enorme nella scelta di quali feature rilasciare e quando rilasciarle, all’atto pratico una vera carta bianca su decisioni strategiche che mi erano state sempre occluse o almeno limitate, in quanto ogni scelta doveva essere condivisa da una tale pila di persone da rendere nei fatti praticamente impossibile i cicli di build-measure-learn.
Dall’altro lato ho visto nascere nei team una entusiasmante (e in certi casi insospettabile) professionalità, i tecnici sono saliti dalla sala macchine e hanno visto in cosa si trasforma il loro prodotto, anzi di più, hanno virtualmente incontrato i clienti che usano il prodotto che loro hanno creato.
Ho abbastanza fiducia in questo sistema da trovare le parole giuste per spiegare la differenza tra il ruolo di un Product Owner e quello di un Project Manager.

Apologia del fallimento

apologia_fallimentoIn Italia il termine fallimento, che già tradizionalmente era associata a concetti come sconfitta e irreparabile tracollo, in questi anni di crisi ha acquisito una accezione a dir poco sinistra, istintivamente associata alla perdita di tutti i diritti e al dramma del suicidio.
Forse è una leggenda l’idea che, come mi riportò un italiano che viveva negli States, oltre oceano il fallimento sia vissuto come una prova di coraggio, un grado del valore di un imprenditore, al punto da poter dire che chi fallisce più volte è uno in gamba, uno che ci prova.
Di certo l’idea che abbiamo in Europa del fallimento non trova un corrispettivo nell’approccio pragmatico del mondo anglosassone, dove il solo fallire non può essere giudicato senza verificarne i costi e gli effetti.
Fallire presto.
Fallire a poco costo.
È questo il punto.

Le metodologie Lean e Agile mi hanno insegnato tanti valori che non sempre sono stato pronto ad acquisire ma di uno di essi sono certo: imparare a fallire il prima possibile e usare le metriche in maniera oggettiva per capire quando andare avanti o quando tornare indietro.
Ho seguito uno webinar sull’approccio lean startup presentato da Francesco Fullone di Ideato. Uno dei concetti che mi ha attirato è stato quello di invalidazione associato al validate learning.
Faccio un passo indietro: già Ries metteva in guardia dall’innamoramento verso una value proposition, e come potrebbe essere altrimenti? Ho avuto una idea, me la sono curata, coltivata, amata, finalmente l’ho applicata e infine l’ho fatta passare al setaccio delle metriche, come potrei a questo punto rinnegarla? A meno che le metriche non siano così esplicite da non poter essere ignorate per lo più avverrà che, istintivamente, si sarà portati a minimizzare i valori che smentiscono l’idea e a dare importanza a quelle che invece la confermano. Questa, secondo Ries, è una delle peggiori trappole in cui può cadere un imprenditore come un product owner, con la conseguenza di ritardare a volte fatalmente il momento in cui si decide che l’idea non è corretta e si fa dietro front.
Torniamo alla invalidazione: invalidare significa assumere un atteggiamento contro ogni logica massacrando la propria idea, cercando in tutti i modi di rinnegarla e dimostrandone la mancanza di valore. Così come nelle teorie su cui si fonda il testing, se l’idea infine passa l’invalidazione potremo affermare che essa è certamente valida. Metodo scientifico.

Difficilissimo!
Chi non vorrà dare almeno una piccola chance alla propria idea, sperando che le sue debolezze dipendano dalla giovane età?

Se cambia il Product Owner

Conoscete le tabelle dei parametri di compensazione da applicare in caso di ingresso di un nuovo team member? Se entra nel team un nuovo sviluppatore, applicare un moltiplicatore di 1,2. Se lo sviluppatore non ha conoscenza di dominio, moltiplicare per 1,5.
Non esistono tabelle per il cambio di Product Owner. Forse per pura scaramanzia, perché alla fine tutti sanno che il moltiplicatore in caso di PO sarebbe costoso e molto, molto proporzionato alla effettiva capacità del PO.
Questo è in effetti ciò che è accaduto nella mia azienda: una nuova posizione da ricoprire ha richiesto una serie di cambiamenti a catena, tra cui la mia sostituzione alla guida del primo prodotto (fase 1) e il mio successivo ingresso alla guida di un prodotto totalmente diverso (fase 2).

La fase 1 prevedeva l’ingresso di un manager tecnico, con una lunga esperienza di gestione delle piattaforme su cui il mio primo prodotto in parte si basava; in altre parole, grande conoscenza del dominio, poca conoscenza degli aspetti commerciali e nulla della metodologia e del suo nuovo ruolo.
Nel corso del primo sprint abbiamo iniziato un generico passaggio di informazioni, nella pratica una serie di incontri lunghi e faticosi nei quali raccontavo gli aspetti diversi del prodotto. Guardavo il collega come se avessi guardato una persona in procinto di affogare, non potevo aiutarlo ma contavo nella sua capacità di nuotare; gli rovesciavo addosso tonnellate di parole e materiali, incroci e matrici di variabili che a me erano familiari ed elementari fino a quando non avevo dovuto spiegarli. Sapevo che di tutte quelle informazioni il nuovo PO avrebbe ben recepito un 30%, e forse un altro 30% sarebbe caduto dimenticato ma sarebbe riemerso al momento giusto, magari supportato da qualche appunto, e infine un’ultima parte sarebbe stata reinterpretata, riadattata o forse dimenticata del tutto.
Se potessi dar(mi) dei consigli retrospettivi proporrei:
1. è la grande occasione per rifare un MOSCOW di quanto fatto e da fare; potrebbe essere sorprendente scoprire quanti precedenti MUST fossero in realtà legati a qualche personale crociata e perdano di priorità nel momento in cui vengano filtrati dalla visione di un altro PO
2. sarà la prova del nove di quanto siamo stati bravi a pubblicare e condividere le informazioni di base, le analisi più rilevanti, i progetti: se siamo costretti a inviare attachment più che link a un vostro repository, wiiki o altro, non è buon segno
3. una delle pagina del repository deve essere: contatti e persone rilevanti, mailing list e processi ricorrenti di comunicazione
4. un’altra delle pagine dovrà essere: vision di prodotto e ipotesi di sviluppi per il futuro
A valle di questa prima fase di condivisione abbiamo speso tre sprint per l’affiancamento: nel primo sprint io continuavo nel mio ruolo di PO in toto, l’altra persona partecipava passivamente; nel secondo le cerimonie operative (planning, review) erano ancora gestite da me mentre gli incontri di grooming dello sprint successivo erano già seguiti da lui, che così iniziava a calarsi nella nuova realtà; nel terzo sprint infine il nuovo PO prendeva ufficialmente le redini del prodotto, solo momentaneamente affiancato in maniera passiva da me.
Alla fine del terzo sprint ho scritto una email di saluti agli stakeholder (simbolica, molti di loro sarebbero stati rimasti per il nuovo prodotto), era un atto dovuto che ha avuto la forza di una cerimonia di chiusura di un’era.

Pochi giorni dopo entravo nella fase 2 spostando le mie cose e sedendomi al mio nuovo posto. Ero un po’ nervoso e lo ammettevo chiaramente, in fondo si lavorava con le persone e i ragazzi che ho davanti sono probabilmente il miglior team di sviluppo dell’intera azienda, non ho dubbi che dovrò lavorare per dimostrami alla loro altezza prima di tutto proprio ai loro occhi. Inizio rassicurando il mio team che non amo le rivoluzioni e i tagli netti, che tutte le trasformazioni saranno dove saranno necessarie e nei tempi che le renderanno sostenibili.
Il processo inverso segue più o meno gli stessi passi della fase precedente, inizia con un primo periodo di passaggi di consegne molto complesso e articolato durante il quale la legge del contrappasso mi fa passare dal medesimo purgatorio di cui io ero stato l’aguzzino pochi sprint prima.
Poi, le altre fasi che vedono una mia presenza sempre più forte nell’attività del team.
Naturalmente, mi calo completamente nel ruolo solo il giorno in cui il precedente PO passa alla sua nuova attività.

Nel giro di due sprint inizio ad avere i primi scontri con la realtà. Alcuni dei modelli che, devo ammetterlo, mi rendevano maledettamente sicuro, saltano di fronte alla inapplicabilità in questo nuovo contesto, a riprova del fatto che una metodologia è elastica fintanto che resta a livello di framework, ma diventa un esoscheletro troppo stretto quando viene applicato come un set di esperimenti e regole fisse.
Ho idea che questa differenza sia proporzionale non tanto alle differenze tra i due team, che in qualche modo sono livellate dalla aderenza alla metodologia Scrum, quanto alla distanza tra i due prodotti.
Il prodotto 1 è un prodotto high end, pochi clienti, per lo più reseller o corporate, con alta capacità di spesa e per lo più con notevole competenza tecnica, sufficiente per lo meno ad aiutarli a valutare un investimento abbastanza consistente.
Il prodotto 2 è esattamente l’opposto: generalmente considerato un prodotto entry level, di utilizzo semplice e costo molto ridotto (da 1/100 a 1/1000 del costo di prodotto 1), fa i suoi numeri grazie all’enorme quantità di vendite; l’utenza è ovviamente la più varia possibile, le cui competenze tecniche possono essere da nulle a molto avanzate.
Questa enorme differenza tra prodotti e soprattutto utenze mi disorienta e mi obbliga a rivedere molti de metodi di approccio.
Qualche esempio.
Sono abituato a estrarre statistiche abbastanza significative delle richieste al supporto tecnico del prodotto 1 prendendo un campione di circa una settimana: nel nuovo prodotto lo stesso numero di richieste arriva in alcune ore e dipende da variabili spesso molto localizzate (orario di attività, problemi momentanei anche limitati, etc.)
Sono abituato a chiamare alcuni clienti, a campione, intervistandoli sulle loro esigenze e traendone spunti importanti: nel nuovo prodotto i clienti sono svogliati, per niente interessati a dirmi i loro problemi, e generalmente poco interessati a partecipare allo sviluppo di prodotto; la loro aspettativa è: tu fai il prodotto come o meglio dei concorrenti, poi giudicheremo noi.
D’altro canto sono abituato a trarre dati poveri e contrastanti dalle analisi di traffico e di comportamento del cliente: stavolta i numeri enormi che mi trovo a manipolare mi consentono di fare delle proiezioni sicure come fossero analisi a posteriori.

La morale dell’esperienza è stata dunque che cambiare il product owner ha un impatto enorme sulla continuità del team e dello sviluppo di prodotto. Non è passato molto prima che abbia iniziato a dirigere lo sviluppo di prodotto secondo la mia personale visione, in parte molto diversa dalla precedente: il team ha spesso accusato questo cambio di direzione ma purtroppo è un effetto collaterale irrinunciabile visto che, in fin dei conti, il mio ruolo esige che il nuovo prodotto diventi il mio prodotto.

Grooming e socialismo reale

groominggrooming / ˈgruːmɪŋ/n. strigliatura f., preparazione f., governatura f.;

In agile si chiama grooming la gestione quotidiana del product backlog, che comporta l’ordinamento delle user stories in ordine di priorità, la divisione delle user stories troppo grosse, la cura delle descrizioni e dei contenuti di ciascuna user story, fino ad arrivare a un backlog che sia più vicino possibile al modello stratigrafico di deposito fluviale (geologi si nasce, qualunque altra cosa si diventa!): elementi grossolani e irregolari in basso, elementi fini e ben lavorati in alto.

Il grooming è una attività che spetta principalmente al Product Owner e in parte al team, con e senza il suo PO: per estensione siamo spesso soliti chiamare grooming gli incontri in cui PO e team lavorano insieme alla preparazione del backlog. In questo senso il grooming è una preziosa occasione di condivisione dei punti di vista, un punto di incontro tra le richieste del cosa (di cui il PO si fa portavoce) e quelle del come.

Non ho trovato mai indicazioni univoche su come organizzare un grooming, credo che nessun Cohn o Schwaber se la sia mai sentita di dare prescrizioni su qualcosa che può avere un’immensa variabilità in dipendenza di tantissimi elementi (team, product owner, tipo di progetto, stadio di maturità del progetto…). Voglio scrivere due cose su come noi siamo stiamo organizzando i nostri incontri di grooming in questo momento: in atmosfera assolutamente agile non è escluso che possa cambiare del tutto idea tra un mese.

Io e il mio team facciamo 2 incontri di grooming generale ogni sprint (che per noi sono di due settimane).

Il primo incontro è l’occasione per volare un po’ più in quota del solito e dare un’occhiata al progetto dall’alto, facciamo previsioni su dove saremo al prossimo sprint e a quello successivo e li contestualizziamo nel planning generale del progetto.

Condividiamo le nostre priorità almeno per i prossimi 6-8 sprint, quindi 4 mesi, e con questo orizzonte diamo un senso alle attività previste per i prossimi due sprint. Si fa una sorta di brainstorming moderato, ci si allinea sugli obiettivi.

E’ un incontro molto bello che i membri del team vivono come una nuova ed emozionante esperienza di partecipazione.

Il secondo grooming generale è invece molto più di dettaglio: si discute davanti a un lista di tasks, o meglio user stories, già abbastanza ben definite e ordinate, si finisce di discutere eventuali punti oscuri e si fa una prima stima di story point per facilitare il lavoro del Product Owner di organizzazione delle priorità e definizione del set definitivo di storie da portare al planning.

Poiché il primo incontro porta ad una analisi molto di massima e il secondo è per contro uno studio molto di dettaglio è chiaro che in mezzo ci deve essere un grosso lavoro di definizione delle user stories e di scomposizione delle attività troppo grandi. Al momento la soluzione più fruttuosa e meno dispendiosa per tutti è stata quella di organizzare dei grooming separati con singole persone o piccoli gruppi (es. con tester, con designers, con sviluppatori di backend, di frontend etc.) e concentrare in questi mini incontri la maggior parte del faticoso lavoro di mediazione tra i diversi punti di vista del “come fare” e del “cosa fare”.

Diciamo che è una soluzione aperta: nei primi 10 sprint della mia vita ho già cambiato pensiero almeno 5 o 6 volte e non posso escludere che anche il processo che ho illustrato possa avere delle modifiche in futuro; diciamo solo che per ora funziona abbastanza.