Agile per Velocisti e Risparmiatori

Praticamente ogni volta che parlo di Agile con aziende che hanno provato ad adottarlo con scarso successo mi sento dire sempre le stesse cose: "Adottando Agile (cioè Scrum, come se fosse la stessa cosa) pensavamo di produrre software almeno 2 o 3 volte più velocemente di prima e ridurre i costi almeno della metà, invece... Sono solo grane!".

Io li guardo un po' perplesso e poi gli domando:"Secondo voi quale è il problema? La sfortuna o qualcosa che non ha funzionato?". Fanno spallucce...

Qualcuno sa spiegarmi dove si parla nell'Agile Manifesto di velocità e di costi? Non è che qualcuno ha delle false aspettative emagari queste false aspettative sono l'evidenza che questo qualcuno non ha capito molto di che cosa sia realmente Agile?

Perchè, vedete, Agile sembra semplice, ma in realtà è molto complesso e sottile... E sbagliare è facile.

Nel manifesto leggete cose del tipo: Collaborare, accettare il cambiamento, massimizzare il valore erogato... Costi e velocità? Non pervenuti. Magari ho letto male io... oppure no.

O forse il problema nasce dall'aver letto un libro intitolato: Fare il doppio in metà del tempo?

La verità è che Agile non serve a fare le cose più velocemente, nè a risparmiare... Quelli sono risultati secondari che si ottengono, se si ottengono, perchè si lavora diversamente e, forse, più efficacemente di altri approcci nelle medesime condizioni. Facciamo qualche esempio:

• Se do priorità alla realizzazione di ciò che ha maggior valore e lo rilascio il prima possibile è ovvio che produco un vantaggio rispetto ad un approccio in cui è tutto trattato allo stesso medo.
• Inoltre, avendo definito le priorità, posso anche decidere di non implementare le funzionalità meno importanti che spesso costano tanto quanto quelle più utili... Ma producono poco vantaggio. (Qui si nota che ho un risparmio indiretto che nasce dalla ricerca del valore. Fare meno cose vuol dire anche risparmiare tempo, e quindi una maggiore velocità, ma sempre ottenuto per via indiretta.)
• Inoltre, se faccio un forte affidamento sul feedback dell'utente, è probabile che riuscirò con più facilità a realizzare esattamente ciò che gli serve ed evitare ciò che non gli serve e, quindi, a produrre un valore maggiore... e costi e velocità solo come risultato secondario.

Ma la vera differenza si ha quando si lavora in contesti altamente variabili o poco definiti in cui un approccio tradizionale è così poco efficace da far risultare l'approccio agile stravincente sia in termini di tempi che di costo proprio grazie al forte valore prodotto dal feedback continuo con l'utente.

E' molto importante avere chiaro che le varie cerimonie e pratiche agili hanno un costo sensibile in termini di tempo e competenze che può essere sensato solo se l'alternativa è fortemente inefficace. Quindi, se siete in un ambiente stabile, in cui i requisiti rimangono validi per mesi o anni, vi dovreste domandare se Agile sia realmente utile per voi e non un aggravio.

Ci sono poi anche questioni legate all'efficacia del Team Agile rispetto alla situazione tradizionale: discorsi legati all'accountability e parolacce simili trovano nel team agile una dimensione completamente diversa e molto più focalizzata. Tutti aspetti da approfondire e valutare attentamente per capire quale sia il vero valore veicolato.

Insomma, senza farla troppo lunga, se avete pensato di adottare Agile per risparmiare o fare le cose più velocemente, è probabile che abbiate bisogno di approfondire un po' di più che cosa sia Agile.