Sommopo

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.