I 5 (+1) argomenti chiave Agile del 2016… fin qui

Prima della pausa estiva, diamo uno sguardo "in retrospettiva" al periodo che si conclude, discutendo alcune tematiche che ci sono apparse piuttosto importanti nel panorama Lean/Agile.

In questo post, riportiamo alcune nostre riflessioni — in ordine sparso e non secondo una “gerarchia” — su una serie di argomenti che ci sono parsi particolarmente significativi nella stagione che si avvia a conclusione:

  • La nuova Scrum Guide
  • Framework per scalare Agile
  • Addio monoliti, benvenuti microservices
  • Contratti agili
  • UX e Service Design si integrano in Agile
  • La crescita del movimento agile in Italia

1. La nuova Scrum Guide

È stata da poco pubblicata la nuova versione della Guida Scrum ufficiale. L’aspetto che riteniamo significativo non è tanto l’aggiornamento dopo tre anni, ma il fatto che nella edizione 2016 sia stato inserito un paragrafo sui valori.

valori di Scrum (impegnocoraggioconcentrazioneapertura e rispetto) sono sempre stati citati a proposito della metodologia ma la novità sta nel fatto che queste considerazioni sono adesso diventate uno dei primi paragrafi della guida ufficiale. Prima ancora di parlare di come funziona Scrum, di quali sono i ruoli, le “cerimonie”, i prodotti e gli strumenti che questa metodologia comporta, si parla dei valori, con l’idea che adottarli aiuti a costruire quella fiducia senza la quale diventa difficile ipotizzare il successo del progetto.

Valori e fiducia

È, secondo noi, un passo importante sul piano concettuale: per quanto efficace e valida, una metodologia non funziona in maniera svincolata dalle persone, dalla loro organizzazione e dalla loro mentalità. Le persone e i loro valori vengono prima di qualsiasi aspetto “tecnico”, specie per una metodologia molto ben strutturata come Scrum. Un approccio “meccanicistico” a Scrum, che pretenda di applicarlo senza una adeguata riflessione su persone e organizzazione, non è adeguato: si sapeva, ma è molto importante che sia stato ribadito proprio nella guida ufficiale.

2. Framework per scalare Agile

L’esigenza di scalare Agile è avvertita da alcuni anni: del resto, se le metodologie agili funzionano con i piccoli team, occorrerà trovare un modo per farle funzionare al meglio nell’intera organizzazione anche se essa è molto grande. Il problema è che metodologie come Scrum nascono e si consolidano proprio per essere usate in piccoli gruppi e una loro adozione su grande scala implica delle modifiche e degli adattamenti.

Da questa necessità nascono le diverse soluzioni: dall’antesignano Scrum of Scrums a SAFe, da LeSS a Disciplined Agile 2.x, dall’Enterprise Transition Framework di Agile42 all’inevitabile approccio “no framework”.

Disciplined Agile 2.x

Il gran numero di soluzioni proposte dimostra che questa è una delle tematiche più importanti degli ultimi tempi: in generale si può dire che siamo di fronte a strumenti validi e ben congegnati.

Quella che potrà essere la discussione del prossimo anno non è tanto stabilire quale di questi framework sia “il migliore”, ma capire se effettivamente la chiave per scalare Agile sia il framework per scalare il progetto o non vada piuttosto ricercata una modalità per scalare il prodotto. Non ci dilunghiamo oltre, ma crediamo fortemente che l’approccio che prevede di scalare il prodotto piuttosto che usare un framework sia un tema su cui si tornerà a discutere nei prossimi mesi.

3. Addio monoliti, benvenuti microservices

Un altro aspetto che sta emergendo molto chiaramente nel dibattito della comunità Lean/Agile è quello relativo al peso degli aspetti tecnologici e dei sistemi informativi preesistenti, che si riflette sull’intera organizzazione e sul modo in cui interagiscono i diversi team.

Accade quindi che si lavori a una transizione in senso agile, concentrandosi sui valori condivisi e sul tipo di relazioni esistenti nell’azienda, ma il cambiamento organizzativo realizzato non si rifletta in effettivi benefici di business: gli aspetti tecnologici e architetturali nati in un contesto non agile finiscono per “riattivare” tutti i limiti che si pensavano superati dal cambio organizzativo.

Occorre un significativo mutamento anche sulla codebase e sul modo in cui i team lavorano su di essa: questo è possibile grazie alla formazione di feature teams e all’adozione di uno stile architetturale a microservices.

Feature Teams

Non è una soluzione facile da applicare:  i feature teams, ossia piccoli gruppi indipendenti in grado di “attraversare” tutta l’architettura del prodotto software che stanno sviluppando, dovrebbero essere il più possibile stabili, interdisciplinari e composti da persone al tempo stesso specializzate e generaliste; dovrebbero inoltre condividere gli stessi spazi. Il loro lavoro è finalizzato a realizzare una caratteristica del prodotto orientata all’utente fimale.

D’altro canto, essi non possono operare agevolmente senza un’architettura a microservizi: uno stile architetturale in cui un’applicazione è composta da processi piccoli e indipendenti che comunicano tra di loro tramite API indipendenti dal linguaggio. Ogni microservice è fortemente disaccoppiato dagli altri e svolge un compito preciso.

Microservices

4. Contratti agili

Un aspetto che ha assunto grande importanza negli ultimi tempi è quello dei contratti agili e della loro effettiva praticabilità. Non è facile combinare la flessibilità insita nell’approccio agile con la rigidità imposta dagli aspetti normativi che rendono un contratto formalmente e legalmente valido (penali, scadenze, costo finale prestabilito, trattamento delle change request etc.).

Va però detto che i contratti che si ispirano a principi agili iniziano a essere accettati e sottoscritti anche da grandi multinazionali, su progetti software di portata considerevole.  Come Agile Reloaded riportiamo l’esperienza fatta  dai nostri partner Intré e MakeItApp i quali hanno  portato a termine con successo progetti “chiavi in mano” basati su contratti a Sprint. I progetti completati hanno visto impegnate in media tra le 5 e le 10 persone, per 15-25 Sprint da due settimane.

Il vantaggio è stato quello di garantire una buona flessibilità nella definizione dei requisiti e nel loro cambiamento; contemporaneamente questo approccio ha favorito il controllo puntuale delle spese, incremento per incremento, su base quindicinale. Per permettere un approccio di questo tipo è necessaria una forte condivisione degli obiettivi del progetto e una grande collaborazione da parte di tutti gli attori coinvolti, primo fra tutti proprio il cliente.  La chiave di successo, a nostro giudizio, sta nel mantenere ben distinti gli aspetti “tecnici” di Scrum (cerimonie, strumenti, etc.) dagli aspetti formali e legali: in fin dei conti le aziende si aspettano di dover firmare dei contratti per loro ben comprensibili e formalmente conformi agli standard, e non dei documenti “onnicomprensivi” in cui siano contenuti sia gli aspetti tecnici che quelli contrattuali.

5. UX e Service Design si integrano in Agile

Un quinto elemento che ha caratterizzato questa stagione è che finalmente si è concretizzato quanto auspicato da molti anni a questa parte:  “grafici” e “sviluppatori” lavorano insieme fin dalle prime fasi della realizzazione del prodotto. E, ancor di più, le indicazioni della progettazione dell’esperienza utente fanno sempre più parte del bagaglio tecnico di chi deve sviluppare.

Customer Journeys

Il fatto che tecniche come le Personas, i Customer Journeys e altre pratiche mutuate dal mondo dell’UX Design siano ormai entrate stabilmente nel novero delle metodologie agili è legato al fatto che c’è stato uno slittamento di paradigma: sempre meno gestione di progetto e sempre più ideazione di prodotto.

6. La crescita del movimento agile in Italia

Molti riscontri avuti in questa stagione 2015-2016 ci mostrano un movimento agile in crescita in Italia. Da una parte, si sono moltiplicate le occasioni di incontro e riflessione per la comunità Lean/Agile italiana; dall’altra, sempre più aziende si dimostrano interessate a queste tematiche.

Italian Agile Movement: conferenze e contributi

Lo Italian Agile Movement (IAM) è diventato più grande e le conferenze in Italia si sono moltiplicate o hanno dato origine a nuovi eventi: Agile for Innovation, Italian Agile Day e miniIAD, Agile Business Day, PO Camp, #play14, e così via.

Come Agile Reloaded ci siamo sentiti partecipi di questi sviluppi: abbiamo tra l’altro preso parte all’organizzazione di #play14 —  in Italia alla prima edizione, che è andata piuttosto bene —; abbiamo avuto la possibilità di presentare tre interventi agli XPDays in Belgio a fine 2015, contribuendo alla tendenza per cui gli italiani non sono più solo solo ascoltatori nelle conferenze internazionali ma partecipano con il loro specifico contributo. In collaborazione con gli amici di MokaByte  stiamo scrivendo la Guida Galattica per Agilisti,  un manuale divulgativo sui temi Lean/Agile che ci auguriamo di concludere entro la fine del 2016 e che in parte è già disponibile.

In breve, abbiamo assistito a un’espansione e a un approfondimento dei temi; è importante che la comunità Agile rifugga la tentazione dell’autoreferenzialità e tenti di rivolgersi a realtà variegate con interessi anche più diversificati. Ma il passaggio da movimento “semiclandestino” a realtà consapevole delle proprie potenzialità è definitivamente avvenuto.

Le aziende scoprono l’Agile

In qualche caso è “moda”, in qualche caso è interesse reale, ma alla crescita del movimento agile in Italia stanno prendendo parte svariate aziende: un riscontro effettivo da parte di chi vuole adottare paradigmi agili all’interno della propria organizzazione.

Esistono aspetti specifici della realtà italiana nell’adozione delle metodologie agili: ciò che è perfetto per una azienda statunitense, non può essere applicato pedissequamente ad aziende italiane che hanno numerose differenze con quel modello.

Dal nostro punto di vista forniamo un dato interessante: da gennaio a luglio di quest’anno ha richiesto i nostri servizi un numero di aziende quasi pari a quello che l’avevano fatto nell’intero 2015, a dimostrare una indubbia crescita di interesse.
Cominciano a essere interessate a un processo di “agilizzazione” anche aziende che non appartengono al settore IT ma che desiderano migliorare il modo in cui vengono gestiti processi e organizzazione.

Alla fine l’Agile finirà per “convertire” i manager classici?