La maggior parte delle grandi aziende ha dei coach agile, ed ha adottato (almeno in parte), delle pratiche agile. Quando però occorre implementare livelli più specifici di metodologie agile, ad esempio nella definizione dei prodotti, coinvolgendo clienti, ricerca e sperimentazione, sembra che le stesse aziende si blocchino. E’ anzi interessante vedere come la maggior parte dei loro dipendenti abbia familiarità con i metodi e la terminologia agile, ma quando si tratta di applicarli concretamente al lavoro accampi un sacco di scuse, dicendo che tutto questo non funzionerebbe nella loro situazione specifica.
Jeff Gothelf, autore del libro “Sense and Respond”, ha cercato di risalire all’origine di questo fenomeno rivolgendosi alla comunità on line per raccogliere tutte le scuse addotte per non implementare le tecniche agile, e altrettante argomentazioni a favore. E ne ha trovate in gran numero! Ecco una sintesi delle nove motivazioni più comuni per cui “…si, ma qui non funzionerebbe”, e delle corrispondenti possibili risposte o soluzioni.
1 “…lavoriamo in un’azienda sottoposta a normative molto strette”. Le aziende hanno bisogno di strumenti di prototipazione rapida, e di un cambiamento nelle relazione leggi/compliance e prodotti per produrre nuove idee.
2 “… i clienti si aspettano prodotti finiti, non esperimenti”. Una possibile soluzione potrebbe consistere nel lanciare “prodotti a livello di prototipo” all’interno di piccoli gruppi di clienti, almeno all’inizio. I test A/B aiutano a ridurre i rischi e a sviluppare con continuità le proprie capacità: ad esempio, parte di un codice che non verrà usato per il prodotto finale a valle di un primo test potrebbe venire utilizzato per sviluppare nuove idee.
3 “… agiamo in modo SAFe (metodi agile a scalare)”. Certo, applicare le metodologie agile a scalare è utile, e soprattutto consente di avere maggiore controllo della situazione, ma quanto contribuisce all’apprendimento continuo e quanto ne beneficiano i clienti? Si può provare a definire l’apprendimento all’interno di ogni ciclo di processo. E, attraverso dei buoni programmi informatici, si può evidenziare quali prodotti e servizi vengono maggiormente usati e come vengono percepiti.
4 “…non siamo un’azienda informatica”. Può anche essere vero, ma questa è l’epoca digitale. Come fa un’azienda a stare al passo con il mercato senza l’uso dell’informatica? Questa anzi deve diventare una parte integrante di come viene prodotto valore per i clienti, e uno strumento fondamentale per migliorare continuamente le linee di prodotto e la customer experience.
5 “… produciamo prodotti concreti”. E come si combina questo con la strategia necessaria per rimanere a galla in un periodo di cambiamento continuo? Non si può forse usare la tecnologia per ridurre i rischi? Per esempio, usare le stampanti 3-D per fare prototipi? Valutare i rischi di spedizione o i tempi e i costi di produzione attraverso un programma informatico prima di iniziare la produzione massiva? I software possono cambiare in maniera significativa il modo in cui è considerata la produzione concreta.
6 “…le metodologie agile sono solo per i team tecnologici”. Se funzionassero attraverso metodologie agile soltanto i team tecnologici, questi avrebbero grandi difficoltà a lavorare con altre parti dell’organizzazione, perché i loro obiettivi non sarebbero allineati. La filosofia al cuore dell’agility può essere trasferita anche ad altri dipartimenti. Quando tutti gli uffici adottano un metodo di lavoro agile, i tempi di produzione possono abbassarsi notevolmente, mantenendo sempre un grande supporto trasversale nell’organizzazione
7 “…non abbiamo tempo per imparare le metodologie agile. Abbiamo delle scadenze da rispettare”. Può anche essere vero, ma produrre e mettere sul mercato un prodotto che non offre valore aggiunto sarà ancora più costoso. Investire un po’ di più nella ricerca di funzionalità desiderabili può fare una grande differenza nel successo finale del prodotto.
8 “… non avere un business plan completamente definito significa non ricevere budget”. Ma come si può realisticamente fare dei piani che vadano oltre l’orizzonte di qualche mese? Come è possibile stimare e anticipare tutte le possibili eventualità? Non sarebbe meglio fare ogni quarter degli aggiustamenti al proprio piano per essere sicuri che sia più accurato?
9 “… gli ingegneri dovrebbero starsene a programmare”. Le persone sono assunte in base alle loro competenze specifiche, ma perché non permettere loro di esprimere tutto ciò che possono da offrire? Lo sviluppo professionale non è limitato alle competenze tecniche, ma coinvolge anche l’avere una prospettiva più ampia del lavoro.
Per il bene dei tuoi colleghi, del tuo team, della tua azienda, dei tuoi clienti e di te stesso, smetti di accampare scuse e inizia a focalizzarti su un approccio più centrato sul cliente, digitale e agile!
Leggi l’articolo completo di Jeff Gothelf sugli approcci agile al digitale – www.medium.com
