Agile / Scrum

Da qualche tempo abbiamo scelto di abbandonare l'approccio classico waterfall, perché abbiamo potuto sperimentare in molte occasioni i vantaggi di un approccio agile nello sviluppo di prodotti software, usando come faro i quattro valori del Manifesto Agile.
L'agilità per noi non è una scelta di tendenza, ma deriva dal fatto che abbiamo capito che per molti prodotti che realizziamo (anche se non tutti) un approccio adattivo è più proficuo.

Abbiamo capito e sperimentato sulla nostra pelle che l'agilità è innanzitutto un mindset, prima ancora che un insieme di pratiche o l'adozione più o meno ortodossa di un framework come Scrum. – ALBERTO TRONCHIN - IT Board e Scrum Master

Si è agili se tutta l'organizzazione ha fatto questa scelta e ne ha toccato con mano i benefici.
Lavoriamo con un dominio di business in cui esistono scadenze perentorie da rispettare per l'uscita sul mercato di un aggiornamento software. Si tratta di scadenze dettate dalle istituzioni e dall'Agenzia delle Entrate, sulle quali non abbiamo margine di manovra, se non molto limitato. In questo scenario, un approccio incrementale e adattivo non è sempre ideale e pertanto dobbiamo cercare continuamente dei compromessi, non aggrappandoci alle tecniche ma ai principi fondanti.

Abbracciamo il cambiamento

Uno dei quattro principi del Manifesto Agile recita: "È più importante rispondere al cambiamento che seguire il piano". Questo significa adottare un processo di sviluppo del software che non considera il cambiamento come qualcosa da rifuggire, ma come una situazione naturale e frequente.
Proprio per questo, i team di sviluppo prodotto ispezionano continuamente il proprio lavoro (fatto e da fare) per identificare i segnali di cambiamento, in modo tale da "abbracciarli" il più rapidamente possibile. Sia il Business che l'IT sono consapevoli che i cambiamenti sono per lo più inevitabili: si possono manifestare come modifiche delle priorità o dei bisogni/requisiti (quindi originati dal Business) oppure come variazioni nei tempi/costi di realizzazione, magari legati ad imprevisti che si presentano in corso d'opera (quindi originati dal team di sviluppo).
Abbracciare il cambiamento significa per noi anche accettare il fallimento e imparare da esso. Quando qualcosa va storto, Business e IT non si focalizzano sulla caccia al colpevole, ma si chiedono: "Cosa possiamo imparare da quanto è accaduto?"

Ispezioniamo continuamente il lavoro fatto

Per poter migliorare, bisogna potersi misurare. Ma per misurare il proprio lavoro, bisogna dedicare tempo all'ispezione di cosa si è fatto e di come lo si è fatto.
In che modo ispezioniamo il nostro lavoro? Al termine di ogni ciclo di produzione (di valore), organizziamo le sprint review, ovvero verifichiamo con occhio critico, assieme a tutti gli stakeholder interessati, se quello che abbiamo prodotto e abbiamo rilasciato è in linea con le aspettative e soddisfa i bisogni. In base ai feedback ricevuti possiamo ritarare il percorso. Inoltre, ad ogni ciclo produttivo, organizziamo le retrospettive di team, durante le quali ci fermiamo ed ispezioniamo il processo che ha portato all'incremento di prodotto realizzato. Da qui possono nascere nuove azioni e nuovi esperimenti, che alimentano il miglioramento continuo del team.

I nostri rituali

L’ispezione e l'adattamento passano attraverso una serie di pratiche e di rituali che abbiamo fatto nostri, ereditandoli in parte da Scrum: