Per Hermes il metodo Agile è quello vincente, ma perché? Questo articolo ti mostra vantaggi e benefici dell’adozione dell’Agile come framework operativo.
Per Hermes il metodo Agile è quello vincente, ma perché?
Dalla nascita della “Metodologia Agile” ne è passata di acqua sotto i ponti, eppure per molte aziende si tratta di qualcosa di teorico, sperimentale, quasi fumoso o semplicemente nuovo.
È vero che il mondo corre veloce e la tecnologia fa passi da gigante, ma per dare l’idea di quanto tempo è passato, la creazione del Modello Agile risale ormai al lontano 2001, quando ancora c’erano le Torri Gemelle per intenderci.
Se in generale molti tendono a tirare una linea temporale immaginaria che divide il mondo tra prima e dopo l’attacco al World Trade Center, potremmo dire che anche nel settore dell’IT e dello sviluppo software vale lo stesso e c’è quindi un “prima”, ma soprattutto un “dopo” la nascita dell’Agile che oggi inizia ad essere una realtà.
Com’era il mondo dell’IT prima dell’avvento dell’Agile
Come detto, l’Agile è arrivato sulla scena da oltre 20 anni, ma fino alla sua creazione – ed in generale fino a poco tempo fa – le aziende lavoravano principalmente con la metodologia Waterfall, che ha sicuramente i suoi vantaggi, ma anche altrettanti limiti che l’Agile si propone di superare.
Il framework Waterfall prevede la creazione di milestone fondamentali durante il percorso di sviluppo che guidano e vincolano rigidamente l’avanzamento di ogni fase.
In parole povere si deve necessariamente e inderogabilmente portare a termine la fase A per poter passare alla fase B, poi alla fase C e così via.
Il metodo Waterfall si presta bene a progetti ben definiti o dove è possibile attingere ad un bagaglio di esperienza pregresso e quindi si va a prendere quel modello noto, magari provando a migliorarlo, ma con la possibilità di partire da una traccia di base.
Questo permette sicuramente una linearità di sviluppo, ma a quale costo?
È chiaro infatti che con questo modello ogni minimo ritardo nella lavorazione si ripercuote negativamente “a cascata” sulle fasi successive.
Waterfall diventa quindi un nome profetico, che porta il progetto ad accumulare ritardi su ritardi in ogni fase, allungando i tempi in media del 50% rispetto a quanto preventivato e arrivando alla meta quando è troppo tardi.
Quando infatti si aspetta di aver completato tutto lo sviluppo per procedere alla prima release del progetto, c’è il rischio concreto di arrivare sul mercato quando la soluzione è ormai vecchia o obsoleta.
Il risultato finale è che in teoria il progetto è stato portato a termine con successo, ma in pratica si è fallito nell’unica cosa che contava davvero: la velocità.
Come hackerare i processi di project management per renderli più efficienti? Nasce l’Agile Manifesto.
La rivoluzione che viviamo tutt’oggi nel mondo dello sviluppo software iniziò sulle montagne innevate dello Utah, nel lontano 2001.
Come detto a quel tempo c’erano le Torri Gemelle svettavano ancora su NY, gli iPhone non erano nemmeno in progettazione (prima release 29 giugno 2007) e se volevi collegarti a internet dovevi sopportare quel rumore ormai considerato “romantico” dei modem a 56k.
Eppure in un tempo così poco tecnologico rispetto a quello attuale, c’era già chi pensava alle soluzioni per migliorare, velocizzare e ottimizzare le performance dei team di sviluppo.
La soluzione fu proprio la nascita della Metodologia Agile, dove 17 “padri fondatori” si incontrarono per scrivere quello che è diventato il loro Manifesto e recita:
“Stiamo scoprendo modi migliori di creare software, sviluppandolo e aiutando gli altri a fare lo stesso. Grazie a questa attività siamo arrivati a considerare importanti:
Gli individui e le interazioni più che i processi e gli strumenti.
Il software funzionante più che la documentazione esaustiva.
La collaborazione col cliente più che la negoziazione dei contratti.
Rispondere al cambiamento più che seguire un piano.
Ovvero, fermo restando il valore delle voci a destra, consideriamo più importanti le voci a sinistra”.
Quali sono i vantaggi concreti dell’adozione dell’Agile per i team di sviluppo?
La cosa che ha convinto definitivamente il management di Hermes di convertirsi alla metodologia Agile è stata aver intravisto l’opportunità di poter ottenere migliori risultati con il giusto sforzo.
Quello che però può non balzare subito all’occhio è che il risultato che pesa non è solo il prodotto finale, ma anche altri parametri come:
- la creatività, perché non seguendo uno schema rigido, ogni membro del team ha la possibilità di apportare valore aggiunto al progetto;
- la soddisfazione del cliente, perché gli aggiustamenti ed i feedback continuo danno modo al committente di comprendere tutte le fasi del processo e la direzione dello sviluppo ad ogni step;
- infine il benessere di ciascun membro del team, perché questo metodologia permette una maggiore autonomia di gestione, permette di sfruttare al massimo le doti di empatia e intelligenza emotiva e riduce lo stress delle deadline stringenti a favore di un approccio più performance based.
A differenza di quanto detto per il metodo Waterfall, il modello Agile è ottimale per tutti quei progetti più immateriali o anche empirici, basati su un’idea astratta o un’intuizione che deve essere tradotta in qualcosa di concreto.
Queste sono le sfide più belle ma anche le più complesse, perché non avendo un modello di riferimento lo sviluppo è tutto work-in-progress e quindi l’Agile è perfetto per la sua capacità di adattarsi come l’acqua che prende la forma del suo recipiente, senza perdere le sue caratteristiche.
Agile di nome e di fatto.
Mettendo allo specchio Waterfall e Agile ci si accorge subito della differenza nel momento in cui si analizza il processo nel suo complesso.
Da una parte c’è Waterfall che potremmo paragonare ad un business plan, dove si prova ad analizzare e prevedere con la teoria ogni possibile scenario, salvo poi scontrarsi con la dura realtà della pratica.
Tonnellate di documenti, pianificazioni millimetriche e deadline incalzanti che però non verranno mai rispettate, ma allora qual è il senso di tanta preparazione a monte?
Chi fa impresa sa bene che i business plan, sono assolutamente necessari, ma nel 99% dei casi non vengono mai rispettati né come tempistiche, né come costi.
A volte addirittura mettendo a confronto la primissima stesura di un business plan e l’outcome finale del progetto, si può avere il dubbio che si tratti di 2 aziende diverse, tanto cisi è discostati dalle previsioni originali.
L’Agile si ripromette di essere proprio questo, abbandonare la rigidità dello schema iniziale e renderlo fluido, adattivo, iterativo e praticamente perfetto.
Questo deriva dal fatto che, dati alla mano, grazie al testing continuo le soluzioni sviluppate secondo il metodo Agile presentano zero difetti, quindi una qualità assoluta.
Giacomo Caturegli, membro fondatore di Hermes e Coach Certificato Agile spiega la differenza tra Waterfall e Agile con una metafora estremamente semplice e d’impatto, per capire i limiti della prima e i vantaggi della seconda.
Immaginiamo che l’obiettivo del progetto sia: “Come devo fare per recarmi in ufficio in centro, qui a Firenze?” Basandoci sul metodo Waterfall la risposta più sensata potrebbe essere: “Con una Ferrari”.
La Ferrari è l’auto più veloce, quindi se ho la necessità di andare velocemente in ufficio, la migliore scelta è una bella Ferrari aziendale, giusto? Sbagliato!
Se seguissimo questo schema, dovremmo prima redigere per bene tutto il “Progetto Ferrari”, facendo la timeline completa delle task necessarie e investendo alla fine 200k per comprare una bella Portofino fiammante (purtroppo il budget è quello che è).
Salvo poi accorgerci che saremo condannati ad ore di traffico ogni mattina, rendendo di fatto inutile tutto lo sforzo organizzativo, nonostante abbiamo scelto la soluzione più veloce sulla carta.
Dall’altra parte invece, usando il metodo Agile il progetto avrebbe preso tutt’altra piega.
Si sarebbero analizzati pro &contro di uno skate (non adatto a tutti), poi di una bici (non male, ma le ciclabili non sono il massimo) e poi magari di un motorino: eureka!
Quindi un motorino è meglio di una Ferrari? Dipende. Dipende da esigenze ed obiettivi ed in questo caso la risposta è decisamente “si”.
Come interpretiamo il modello Agile in Hermes?
La squadra di Hermes prova ad unire tecnica e cuore attraverso un perfetto bilanciamento di tutte le sue componenti. Non è un segreto infatti che la differenza, l’elemento che rende tutto più efficace e potente sia infatti qualcosa che nulla a che vedere con le skill tecniche, ovvero l’empatia che viene insegnata anche a partire da zero nel Talent Care di cui abbiamo parlato qui.
La vision è riuscire a coltivare talenti che, oltre alle skills tecniche, siano in grado di sviluppare un’intelligenza emotiva tale da permettergli di essere performanti, felici e di saper trasmettere i benefici di questo approccio a chiunque sia intorno a loro.
Questo diventa fondamentale soprattutto quando il talento deve integrarsi nel team del cliente ed è qui che Hermes riesce a fare la differenza nella creazione di nuove soluzioni.
Dalla teoria alla pratica, come sfruttare l’efficienza dell’Agile per il tuo progetto con Hermes?
Basta trasporre l’esempio appena fatto della Ferrari e del Motorino su un qualsiasi progetto di sviluppo, per accorgerti subito di quanto tempo e denaro può farti risparmiare un team che lavora sulle basi del framework Agile.
Ovviamente c’è bisogno che le risorse, anzi i talenti come ci piace chiamarli qui in Hermes, siano formati sotto tutti i punti di vista per essere capaci di interpretare e anche condividere questa modalità operativa.
Questo è esattamente ciò che facciamo ogni giorno attraverso i nostri servizi e che puoi avere anche per la tua azienda o il tuo progetto: formiamo talenti e forniamo ai clienti le soluzioni customizzate in base all’obiettivo da raggiungere.
Con “Wings-Two-Fly” abbiamo un gioco di parole che identifica le 3 modalità di supporto che possiamo offrire ai nostri partner.
Fly è il clou della nostra attività, che prevede una consulenza completa che parte dall’analisi dei processi, passando per la definizione di nuove metriche di misurazione fino alla proposta di una soluzione e alla sua successiva implementazione.
