Trovare il giusto Agile Coach

Nel 2004 e 2005, sempre più team sono passati ai metodi agili e spesso avevano bisogno innanzitutto di consulenza e formazione. In molti casi, però, dopo i training dovevo recarmi nelle aziende per rimettere in ordine il disordine lasciato dai trainer. Erroneamente, all'epoca avevo supposto che questo sarebbe stato un problema solo finché i nuovi team agili – specialmente nelle aziende che sviluppano software standard – avessero dovuto ancora accumulare esperienza. Purtroppo il problema dei cattivi trainer e coach non è ancora scomparso. Sebbene molte aziende abbiano già scelto buoni trainer, a mio parere sono ancora piuttosto l'eccezione.

Come per molte altre cose, spetta naturalmente al cliente trovare il miglior trainer per sé. Tuttavia, quando un team ha bisogno di formazione, è molto probabile che coloro che devono prendere questa decisione non abbiano ancora esperienza in merito. L'intenzione dietro questo articolo è quindi aiutare le aziende che sviluppano prodotti a trovare i trainer e coach giusti per i metodi agili.

Diversi fattori per la ricerca del giusto Agile Coach

1. Nella maggior parte dei casi, il software viene ancora sviluppato per scopi interni (IT) o specificamente per un determinato cliente. Pertanto, molti trainer agili non si trovano ancora a proprio agio con le aziende in cui si sviluppano soluzioni per il mercato di massa. Naturalmente non si vuole nemmeno essere l'azienda su cui un tale trainer fa pratica. Per questo è importante sapere in anticipo se il potenziale trainer comprende la differenza tra IT (interno), sviluppo software personalizzato e sviluppo software standard.

2. Nelle aziende che sviluppano software standard ci sono ruoli molto diversi rispetto ad altri tipi di software. Un potenziale trainer deve comprendere il ruolo del Product Manager, del Product Marketing, del team UX, degli Interaction Designer, dei Visual Designer e degli User Researcher.

3. Il trainer deve sapere come funziona la collaborazione tra Product Manager e UX Designer con il team di sviluppo agile. Il trainer dovrebbe avere esperienza personale con il Dual-Track Agile (sviluppo su due binari) – ovvero con Product Discovery e Product Delivery.

4. In un'azienda software, in certi casi bisogna essere in grado di fare impegni concreti e fornire indicazioni affidabili sui tempi di completamento. Questo deve avvenire con integrità e bisogna essere consapevoli che le roadmap convenzionali sono spesso piene di elementi che non portano realmente valore al cliente. Il trainer deve quindi capire come si prendono tali impegni e come vengono gestiti in un team di prodotto.

5. Nei team di sviluppo per software standard, la visione del prodotto è estremamente importante per creare un contesto e motivare il team. Un trainer per metodi agili deve quindi comprendere il ruolo chiave della visione del prodotto e della strategia e anche sapere come questo si collega con Product Discovery e Delivery.

6. Con il software interno, molti trainer per metodi agili pensano di essere abbastanza veloci quando provano un paio di idee ogni Sprint di due settimane. Con il software standard, tuttavia, questo verrebbe considerato incredibilmente lento. Assicuratevi che il vostro trainer abbia capito che la velocità è estremamente importante per le innovazioni e come il Dual-Track Agile ci aiuta a validare la maggior parte delle idee senza dover scrivere codice.

7. Nelle organizzazioni per software standard si ha un ciclo continuo in cui si costruisce qualcosa (prototipi e produzione), si misurano i risultati, si impara da essi e si ripete il processo. È molto importante che il trainer comprenda l'importanza di questo ciclo nonché dei prototipi, delle analisi e degli A/B test per il processo decisionale, il testing e l'apprendimento continuo.

8. Dal punto di vista culturale, c'è una grande differenza tra gli sviluppatori in un'organizzazione IT e quelli in un'organizzazione per software standard. Il trainer agile deve sapere che il livello di esperienza e competenze degli sviluppatori varia notevolmente e l'approccio deve essere adeguato di conseguenza. Molti degli sviluppatori hanno molta più esperienza nello sviluppo di prodotti reali rispetto alla maggior parte dei trainer. Pertanto, trainer con l'atteggiamento sbagliato possono rapidamente fallire nel guadagnarsi il rispetto del team.

9. Un'altra grande differenza è che un team in un'organizzazione IT deve soddisfare le esigenze dell'azienda. Il team di prodotto in un'organizzazione per software standard è lì per sviluppare soluzioni per i clienti in un modo che sia realizzabile e redditizio per l'azienda. Questa non è una differenza trascurabile. Il trainer deve capire che questa non è un'organizzazione di servizi orientata a soddisfare le esigenze dell'azienda.

10. In definitiva, è fondamentale che il trainer non solo comprenda le aziende di software standard, ma anche i requisiti e i metodi dei servizi SaaS (Software as a Service) mission-critical. Temi come scalabilità, affidabilità, tolleranza ai guasti, prestazioni, monitoraggio e controllo, automazione dei test e debito tecnico non sono più opzionali ma un must assoluto. Inoltre, nello sviluppo di software standard non c'è spazio per un'adesione dogmatica e cieca ai processi. Alcune persone tendono a confondere i mezzi per raggiungere un obiettivo con l'obiettivo stesso nei metodi agili. L'unico obiettivo che conta davvero è un prodotto di successo.

Conclusione

Quando scegliete un trainer o coach per metodi agili, dovreste tenere presente che l'azienda per cui lavora spesso non è così determinante quanto la persona stessa. Verificate quindi il potenziale candidato e scoprite se dispone dell'esperienza con aziende di software standard di cui avete bisogno.

In generale si può dire che un trainer viene da voi, vi spiega la teoria e poi se ne va. Un coach, invece, applica effettivamente i metodi con il vostro team nel vostro ambiente unico.

Questo testo proviene dal blog di Marty Cagan ed è stato tradotto in italiano da noi.