Tag Archive for team

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.

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.

Chi scommette sul fallimento del progetto (e viene pagato per questo)

C’è un ruolo nel team che scommette sul fallimento delle storie. Cerca l’insuccesso con i clienti. Ama trovare la magagna.

E’ il tester.

Tutto il team, PO compreso, desiderano creare valore in un clima di zelante ottimismo. Il ruolo di tester invece prescrive la ricerca dell’insuccesso di una user story: questo fa della persona che ricopre tale ruolo un elemento chiave del team, in quanto lui solo si sente votato alla ricerca del fallimento.

Persino il PO, più o meno consciamente, desidera il successo delle user stories e ne vede il fallimento come un impedimento al normale procedere del progetto, così che lui stesso diventa il peggior nemico della qualità di quello che viene rilasciato, a volte anche accettando una certa quantità di debito (tecnologico o di usabilità) pur di rilasciare la funzionalità. Per sua fortuna il tester non ha pietà.

In “lessons learned in sofware testing” la cosa prende una piega epica: “sull’isola dei tester essi erano destinati per sempre a cercare ciò che non potrebbe e non dovrebbe esistere, sapendo che avere successo porterà miseria agli Dei”.

Parlando di tester il mio coach era stato ancora più illuminante.
Citando Diana Larsen ha presentato il valore del ruolo di tester come l’effetto di arricchimento intellettivo apportato da un elemento di eterogeneità: se in un team di sviluppatori si inseriscono dei designers, o se in un team di soli maschi si inserisce una signorina (questo era proprio l’esempio fatto), l’effetto è un ampliamento della curva gaussiana delle possibilità di variazione del punto di vista e quindi della soluzione a un problema logico o tecnico, e di fatto un ampliamento statistico del range di variabilità, e di fatto un miglioramento della qualità.
L’introduzione di un tester, che ha una visione esattamente speculare a quella di un qualsiasi altro team member, è un valore inestimabile per un qualsias gruppo di lavoro.

La giornata della coscienza cosmica di prodotto

La ricetta è semplice: per alcune ore avremmo imparato a lavorare e pensare come un cliente, replicando le azioni e gli errori dei clienti, trovandosi a tu per tu con le loro difficoltà quotidiane.

Gli ingredienti erano altrettanto semplici: il team (me compreso) diviso in tre gruppi.
Altrettanti insegnanti provenienti dal supporto tecnico, lupi di mare informatico con lunghissimi anni di esperienza nei più travagliati oceani dell’assistenza, non marinaretti dalla risposta standard ma vecchi ammiragli della tecnologia avanzata.
Server di test, quanto basta per distruggerli e ricrearli.
Un programma del corso.

Il risultato è stato interessante, abbiamo guardato i nostri prodotti da una prospettiva nuova trovando dei punti di forza che non avevamo mai immaginato e al contempo scoprendo degli ostacoli che in certi casi richiedono solo un minimo impegno da parte nostra per essere rimossa, ma con grande beneficio per chi sta dall’altra parte dell’interfaccia.

Ci sono alcuni margini di miglioramento: vorrei ad esempio che qualcuno, la prossima volta, ci aiutasse a passare il mood dei nostri clienti, come i nostri clienti sentono il prodotto, cosa li rende positivi e cosa invece li allontana. Mi piacerebbe ipotizzare altri usi del nostro prodotto, meno scontati ma più professionali.
Mi piacerebbe che la giornata si chiudesse con una sessione di retrospettiva dove commenti e scoperte possano essere condivisi a uso di tutto il team.

Gran finale, cena di team e istruttori dalla mitica Gilda.