Le cose che mi rendono nervoso di Agile

Potreste dire di non avere dubbi sulle metodologie agili? C’è chi ha pubblicato le 10 cose più odiate dell’Agile:
http://www.allaboutagile.com/10-things-i-hate-about-agile-development/

I risultati di un survey inviato ai primi team agile della azienda per cui lavoro mi hanno portato a riflettere su alcune questioni che considero ancora aperte, e mi sono chiesto: c’è qualcosa che non capisco o non mi piace nelle metodologie agili?

Ho identificato 4 cose che mi rendono nervoso:

1. Agile non è l’arma fine di mondo. La società per cui lavoro ha abbracciato Agile con un entusiasmo tipico delle aziende giovani e dinamiche, quindi certamente abbiamo sofferto poco la serpeggiante sfiducia anti agile riportata dall’articolo, ma il rischio contrario è che porzioni dell’azienda possano accogliere l’Agile come il messia inviato da una entità superiore per dimezzare miracolosamente i tempi di sviluppo e migliorare morale e produttività. Le metodologie che usiamo servono a guardare tutto ciò che facciamo con l’occhio vigile del cliente e quello parsimonioso dell’investitore ma non ci salvano dai pericoli quotidiani del nostro lavoro.

2. siamo sicuri che con Agile si proceda più velocemente? Le tante pratiche e cerimonie, la partecipazione a community of practice, incontri, grooming etc. migliorano enormemente la qualità del prodotto e quella della vita di chi lavora, rendono felice il cliente e soddisfatto l’investitore. Ma si corre anche più veloci? Da verificare (non facile, bisognerebbe avere due team pilot, stesso progetto ma metodologie opposte).

3. quanto è capace il team di essere il capo di se stesso? L’incubo di H&R: quanto vince il naturalissimo e per altri versi vantaggioso spirito corporativo del team sull’oggettività nel giudicare un suo membro? E’ possibile la peer evaluation? Un team può fare una scheda di valutazione di un membro se ci sono di mezzo soldi e incentivi di vario tipo? Il team sarebbe in grado di allontanare un membro manifestamente improduttivo ma amabile? Se me lo chiederete in pubblico negherò di aver mai fatto simili domande…

4. può un development team lavorare con agile quando il resto dell’azienda non lo fa? Molto difficile, il marketing dovrebbe gestire iterativamente i lanci di prodotto, l’help desk dovrebbe poter ricevere una formazione sul prodotto in maniera incrementale anche ogni settimana se necessario, la gestione personale dovrebbe essere completamente calata nelle logiche di team. Non sempre però questo riesce con facilità e diventa necessario coltivare una lingua comune che consenta lo scambio di informazioni anche tra mondi molto diversi.

L’incontestabile logica dei numeri

L’immersione nei numeri è un bagno rilassante nel pragmatismo delle esatte quantità, che non sono mai ne’ troppo orribili ne’ troppo piacevoli. Sono solo numeri, non ci raccontano la realtà ma possono aiutarci a confrontarci con la realtà quando ci perdiamo nei meandri delle congetture e delle supposizioni.
Inoltre, hanno la capacità di farci volare più in alto quando la quotidianità delle nostre attività finisce per stringerci intorno al particolare, al momentaneo.
Ci danno una visione più grande delle cose.

Mi è piaciuto l’incontro che abbiamo fatto con il nostro Sales manager; una persona che non solo maneggia numeri, ma che senza dubbio li sa raccontare, li rende vivi e parlanti.
Insieme a lui abbiamo guardato le tristi cifre e i trend negativi che con il nostro lavoro siamo chiamati a invertire, non ci sono mai stati presentati come spauracchi ma piuttosto come facili opportunità di crescita, ci hanno invogliato a rilasciare subito il valore che sappiamo di avere già ora in mano, senza aspettare la perfezione, perché i numeri (e i clienti che li generano) stanno aspettando già da troppo tempo.

I numeri sono rilassanti quando non cerchi di forzarne l’interpretazione: tramite le parole del Sales manager ci hanno raccontato gli errori fatti in passato, le strade che non dovremo più percorrere perché hanno già dimostrato di essere chiuse, ci hanno indicato i successi e spiegato perché certi processi hanno funzionato e altri no.
Da rifare presto, quando questi numeri dipenderanno dal nostro 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.

Chi guarda oltre l’orizzonte

Voi siete Product Owner. Siete voi che andate al meeting internazionale a nord di Hannover, con due cambi di aereo e un’ora di taxi. Siete sempre voi che, vincendo la vostra atavica timidezza, incontrate il CEO della multinazionale con una banale scusa (apparentemente casuale, in realtà l’avete creata a tavolino in giorni di lavoro). Siete ancora voi che siete riusciti a convincere l’azienda a pagarvi (caro) quel famoso report di Netcraft che vi da gli orientamenti del mercato.
Siete voi, insomma, che avete l’onere e l’onore di avere mezzi e tempo per guardare oltre l’orizzonte del vostro team e della vostra azienda, e sarete sempre voi a dover riportare queste informazioni al team.
Ogni due settimane, il mercoledì subito dopo la review, ho organizzato un incontro ricorrente con il team che si chiama semplicemente “Numeri”. L’idea è di dedicare uno spazio di un’ora circa alla condivisione dei numeri relativi al prodotto che sviluppiamo: ricavi, margini, percentuali di vendita online e tramite sales force, crescite e decrescite rispetto all’anno passato etc.
Un giorno mi è stata fatta dal team stesso una richiesta esplicita: “ok il nostro trend, ma andiamo bene o male rispetto al mercato?”. Avevo una risposta solo in parte basata su dati reali.
Così ho deciso di correre ai ripari, ricordando che la risposta alla domanda del titolo, chi guarda oltre l’orizzonte, è: prima di tutto il Product Owner, ed è il Product Owner che indica cosa c’è lontano e se necessario passa il binocolo a chi gli sta accanto, ai componenti del team come agli stakeholder, in modo che tutti quelli che gli stanno intorno vedano alla fine lo stesso brillante futuro.
Il mio incontro del mercoledì si è quindi arricchito di dati e riferimenti del mercato in cui lavoriamo, ad esempio nel mio caso:
* dati da Netcraft, costosi ma utili e ben presentati
* dati pubblici di Alexa, di Webhosting.info etc.
* correlazione con i nostri dati attuali e storici, andamento rispetto all’anno precedente etc.
* random, infografiche trovate in rete su dati statistici generali.
Il team apprezza, e apprezzo anche io che nel lavoro di rielaborazione e preparazione per la presentazione ho l’occasione di rivedere e metabolizzare i dati, facendoli diventare una parte indissolubile del bagaglio di conoscenza di prodotto.

Favorire la partecipazione alla review

Il prodotto che io e il mio team gestiamo interessa parecchie persone all’interno della nostra azienda.
Queste persone sono sparse in 8 uffici diversi distribuiti in 6 paesi europei.
Le nostre sprint review sono perciò necessariamente in inglese e gestite in remoto con uno strumento che consente di organizzare una multiconference con condivisione di schermo e chat.
Ciò nonostante, è tutt’altro che scontato che queste persone mantengano un interesse e una partecipazione attiva alle review, visto che noi siamo solo uno degli otto team di prodotto (ciascuno con la sua review) e sopratutto visto che molti di loro ci stanno seguendo da 48 sprint review.
Immaginate quindi la soddisfazione nel riscontrare la presenza di 25 partecipanti all’ultima sprint review, praticamente tutti i responsabili helpdesk, marketing e vendite e tutti gli esperti del prodotto in esame in ognuno dei paesi in cui siamo presenti.
Alla fine della review ho fatto i complimenti al mio team: aver mantenuto l’attenzione e l’interesse di queste persone per così lungo tempo è un successo conquistato con un lungo lavoro fatto di vittorie, errori, sconfitte, dietrofront e ripartenze. Bravi!
Cosa è che rende interessante e partecipata una review ad alto rischio di incomunicabilità come la nostra?
Nel tempo ci siamo resi conto che dovevamo trovare un modo di compensare un livello medio di conoscenza dell’inglese non proprio eccelso e una certa reticenza alla comunicazione in pubblico. Ecco come abbiamo lavorato.
La review si compone di sessioni di presentazione; in ciascuna sessione ogni team member mostra un lavoro, una feature, un risultato, uno sviluppo, il prodotto di una attività concluso nello sprint appena terminato.
Why & What
Ogni sessione viene introdotta da una slide che illustra il tipo di sviluppo e dunque il perché quello sviluppo è stato fatto (cioè le motivazioni e le esigenze che sono alla base di quella scelta) e il cosa è stato in pratica fatto. Se necessario, e per lo più lo è, alcuni link rimandano alle aree di preproduzione dalle quali i risultati del lavoro saranno mostrati.
Esempio:
Gestionale delle iscrizioni – interfaccia di verifica e validazione delle iscrizioni
Perché: l’attività viene fatta ad oggi manualmente con notevole dispendio di lavoro
Cosa: nell’area di backend abbiamo inserito una lista delle iscrizioni che possono essere validate o rifiutate
Link: area di gestione
Il tutto, ovviamente, in inglese.
Uso della chat
La review, come detto, è in inglese, ma i partecipanti parlano le lingue più svariate e non sempre si sentono a loro agio nel gestire una conversazione in inglese. Scrivere è immensamente più facile per tutti.
Dunque, usiamo lo strumento di chat per interagire con i partecipanti, chi vuole può scrivere una domanda o un commento e uno dei team member più senior è incaricato di rispondere alle domande oppure, se necessario, avvertire il resto del team e il Product Owner che c’è una domanda di interesse generale che vale la pena di essere risposta a voce. Raramente c’è la necessità di aprire l’audio del richiedente e interagire direttamente, ma se desiderato ovviamente si fa.
What’s next

La sprint review si chiude sempre con una slide finale sugli sviluppi previsti per lo sprint successivo: ovviamente questa viene presentata dal Product Owner, che anche in questo caso risponde alle domande in proposito.
Ricordo le prime review dove la maggior parte dei partecipanti veniva nella nostra stanza e per creare una atmosfera accogliente e rilassata facevamo trovare qualche dolcetto. Quando l’interesse crebbe nelle sedi estere mi chiesi con cosa avremmo sostituito quello “sweet welcome”; credo che a distanza di alcuni mesi abbiamo trovato una formula altrettanto confortevole e che, oltretutto, non favorisce la carie.