Riorganizzare l’azienda e i progetti con la metodologia Agile, il caso di Register.it

Si parla spesso di metodologia Agile in riferimento al software, alla organizzazione di team di sviluppo e all’approccio da utilizzare nella programmazione per nuovi progetti, capita invece meno frequentemente che si parli di Agile in azienda, nell’organizzazione dei team e nella gestione dei progetti.

Si parla spesso di metodologia Agile in riferimento al software, alla organizzazione di team di sviluppo e all’approccio da utilizzare nella programmazione per nuovi progetti, capita invece meno frequentemente che si parli di Agile in azienda, nell’organizzazione dei team e nella gestione dei progetti. In realtà ci sarebbe molto da dire e soprattutto da studiare, Marco Chiaverini, Manager di Dada, me lo ha fatto capire in tante risposte e io credo che valga la pena approfondire alcuni dei suoi spunti per capire come rendere davvero snella l’organizzazione di un progetto tramite queste metodologie. 

Non stiamo parlando solamente di teoria, Marco è sulle pagine di HostingTalk.it proprio per spiegare come Dada, uno dei più grandi gruppi italiani del settore IT, webhosting e registrazione domini, stia applicando questa metodologia di lavoro ad un numero sempre più elevato di progetti. Noi ne abbiamo avuto un assaggio con il lancio del nuovo prodotto Server, il cui team è stato uno dei primi esempi di riorganizzazione e adattamento ad un approccio Agile.

register-marco

Marco ha delineato in poche risposte quali siano i passi principali per l’implementazione di un modello Agile e come questo si possa applicare ad una intera azienda, anche di dimensioni medio grandi. Non abbiamo dimenticato di parlare di software e di sviluppo Agile, essendo Dada impegnata anche nello sviluppo di propri prodotti interni. Un’intervista davvero interessante che consiglio di leggere attentamente.

La parola a Marco. 

1) Ciao Marco e benvenuto su HostingTalk.it, due parole su di te e sul ruolo che ricopri in Dada

Ciao. Attualmente sono responsabile dello sviluppo di Prodotto della Business Unit Domini e Hosting di Dada a cui fanno capo Register.it, Nominalia, Amen, Namesco.

 

2) Marco, veniamo subito al punto, Dada ha adottato da un po’ di mesi una metodologia Agile. Di cosa si tratta e cosa si intende con il termine Agile?

Si è vero. Stiamo utilizzando Scrum e Kanban ma più che di agile parlerei di un mutato approccio allo sviluppo del software e all’organizzazione aziendale. Riuscire a descrivere Agile in poche parole è impresa ardua perciò partirei dalla definizione di agilità: L’abilità di adattarsi rapidamente e deliberatamente al cambiamento di contesto e al cambiamento delle richieste controllando i rischi.

Ancora oggi per sviluppare software usiamo processi derivanti dal modello industriale ottocentesco della catena di montaggio. Agile parte dall’idea che sviluppare software è complesso e non predeterminabile da processi definiti a priori perciò introduce l’approccio empirico basato sull’esperienza e la sperimentazione.

Tecnicamente vengono definite metodologie agili tutte le metodologie leggere e poco prescrittive che indicano ruoli, regole di ingaggio, tecniche di lavoro che vengono utilizzate da piccoli team collocati che sviluppano software in brevi cicli temporali privilegiando la comunicazione faccia a faccia, riducendo al massimo gli sprechi. In concreto, però, agile è molto di più di un insieme di metodologie, è un set di strumenti mentali per la gestione aziendale e l’organizzazione ma soprattutto è una cultura diversa perché porta con sé il focus sulla qualità (Test First, Testing Automation), sovverte la logica push con la logica pull, introduce la trasparenza e i concetti di “Inspect and Adapt” e si basa sulla bottom-up intelligence, la auto-organizzazione e il cambiamento continuo. Mi sento però di sfatare un mito: agile non significa anarchia ma mette a dure prova le competenze e i credo delle persone a tutti i livelli compresi i manager.

Per approfondire purtroppo in italiano si trova davvero poco materiale perciò consiglio di partire dai libri di Schwaber, Sutherland, Cohn, Appelo, Larman e Kniberg.

 

3) Passiamo ad un esempio pratico, il team di Dada che ha lavorato sulla nuova offerta Server ha adottato la metodologia Agile. Ci porti degli esempi concreti per capire che benefici ha apportato?

Il team di Dada che ha lavorato allo sviluppo della nuova offerta di server dedicati si chiama Kiss. Si! proprio come il nome della band, in Dada i team autodeterminano il loro nome, i loro spazi di lavoro e i loro processi.

I Kiss sono stati formati a dicembre 2011 con lo scopo preciso di costruire il nuovo prodotto con tutte le competenze necessarie: due senior backend developer, 2 senior front-end developer, un User Interface Designer, un tester, un Content developer, uno Scrum Master, un Product Owner, una stanza completamente dedicata, lavagne, pareti per affissioni, flipchart, tanti pennarelli e tanti post-it.

I fattori di successo sono stati molteplici, primo fra tutti la qualità dei prodotti rilasciati.

Oltre a questo l’aver allocato le persone del team al 100% su un unico progetto ci ha permesso di aumentare incredibilmente il focus sul progetto eliminando così il context switching.

L’introduzione delle pratiche tecniche come Test driven development hanno comportato un numero esiguo di bugs e defects e la possibilità data al team di decidere come realizzare il prodotto ha chiaramente dimostrato che un team di sviluppatori ha idee innovative e creatività.

Il beneficio che mi sta più a cuore è che i Kiss sono oggi un team di persone motivate che si sentono realizzate in Dada e si sentono parte attiva di Dada e hanno imparato tantissime cose nell’anno passato nel team.

 

4) Nel corso di Better Software lo scorso Ottobre parlavi della difficoltà di implementare il metodo Agile in una grande azienda, quali sono i consigli che ti senti di dare a chi si accinge ad adottarlo nella propria compagnia? 

Un’altra lezione di agile è “imparare dai fallimenti” stabilendo il fallimento come una condizione essenziale per l’apprendimento.

Pensando in retrospettiva mi è chiaro quanto la crescita che abbiamo fatto come azienda e singolarmente come persone sia principalmente dovuta al vivere sulla propria pelle gli errori e i problemi che agile ti porta ad affrontare. Un fattore chiave è investire in formazione, incuriosire tutti per coinvolgerli e studiare, leggere, approfondire. In Italia stanno nascendo e sono nati tanti movimenti che promuovono il cambiamento culturale, partecipare e assistere agli eventi come Better Software o Agile Day è stimolante e istruttivo.

Detto questo, il primo impedimento che ogni azienda si trova ad affrontare è la resistenza al cambiamento e avvalendosi dell’aiuto di coach esterni all’azienda come abbiamo fatto noi è certamente di aiuto per velocizzare il processo.

 

5) Come avviene in pratica la scrittura e il rilascio di nuovo software con la metodologia Agile?

All’inizio di ogni iterazione il team cross funzionale si accorda con il Gestore del backlog di attività di progetto sulle funzionalità che svilupperà durante l’iterazione. Da quel momento, fino alla conclusione dell’iterazione che avviene con la Review il team fa tutto quanto è necessario per trasformare le richieste di feature in incrementi software completate al 100%, funzionanti, testate e potenzialmente rilasciabili in produzione.

Come tecnicamente avviene la scrittura del codice non è molto dissimile da come avveniva in precedenza con il fattore distintivo dell’introduzione delle pratiche di unit testing, pairing e code review, test automatici, test driven development, refactoring, continuous integration.

 

6) Il team che si è occupato dello sviluppo del prodotto Server è un esempio, quali altri sono coinvolti? Come li avete scelti?

Dada è ancora nel pieno del processo di Transizione ad Agile cominciato ormai più di un anno fa. Abbiamo iniziato con due team Pilota che hanno utilizzato Scrum: i Kiss e i Crash Test Dummies. Li abbiamo formati in base alle esigenze del progetto che dovevano realizzare affinché avessero tutte le competenze e le conoscenze di dominio necessarie al completamento del progetto riducendo al massimo possibile le dipendenze da team esterni.

 Successivamente abbiamo deciso di fare “scaling” a tutta l’organizzazione di sviluppo di prodotto Domini e Hosting. Oggi abbiamo 6 team cross funzionali che utilizzano scrum con iterazioni di 15 giorni. La fase successiva è quella del cambiamento organizzativo e quindi lo scaling di agile a tutta l’organizzazione aziendale che coinvolge tematiche HR, di pianificazione industriale e in generale una riscrittura di molta parte dei ruoli manageriali e dei percorsi di carriera.

 

7) Prima di passare a questa metodologia di sviluppo avete preso in esame altri casi simili, sempre nel settore webhosting/domini/servizi web?

Ovviamente si. Ci sono tantissime storie “from the trenches” di team che hanno iniziato ad usare XP, SCRUM, Kanban e aziende che hanno fatto transizioni ad Agile. Molte sono documentate in letteratura e in generale sono storie di aziende che sviluppano prodotti software, non specificatamente aziende del nostro settore. Ad ogni modo credo non sia un segreto che Google stessa sia organizzata in piccoli team cross-funzionali e che Agile sia utilizzato in Microsoft, IBM, Spotify, SalesForce e tante altre.

 

8) Quanto dici sembra che sia di vero aiuto per l’azienda, ma è pensabile implementare il modello anche su una piccola azienda?

Ritengo che sia ancora più facile passare ad agile in aziende più piccole perché tendenzialmente hanno strutture organizzative meno codificate e meno strati di processo e meno livelli gerarchici. Il Loop di feedback è per natura molto breve, i clienti sono a diretto contatto con chi sviluppa il prodotto ed in generale c’è molta più disponibilità a ricoprire più ruoli.

 

9) Quali sono gli svantaggi, o i pericoli se vuoi, di lavorare con un modello agile?

Utilizzare un modello empirico non ha svantaggi perché si basa sul guardare la realtà e non ostinarsi a credere nella magia. Usare Agile significa ammettere che sviluppare software è complesso e pieno di rischi e richiede coraggio, fiducia e determinazione. L’unico rischio, soprattutto per le grandi aziende, è che agile sia interpretato come un cambiamento a tutti i costi anche di ciò che funziona. Agile significa rivoluzione culturale ma non necessariamente significa il sovvertire tutte le regole di business e le strutture aziendali che fino ad oggi hanno funzionato.

 

10) Venendo ad un trend crescente, per le startup si parla del famoso modello “lean”, trovi anche qui dei punti in comune con il modello Agile?

Lean affonda le sue radici nel Toyota Production System e quindi è addirittura precedente ad Agile.

Si può sicuramente affermare che le metodologie leggere e i valori di Agile siano perfettamente poggiati sui valori e i principi lean e quindi le sovrapposizioni sono moltissime.

Rispetto per le persone, Riduzione dello spreco, Ritardare al massimo le decisioni, consegnare velocemente, ottimizzare il sistema sono solo alcuni dei valori Lean che stanno alla base di Kanban ma anche di Scrum e XP.

Si può dire che per essere Agili si deve essere Lean ovvero snelli, frugali, minimali, essenziali.

Consiglio la lettura di Tom e Mary Poppendieck per chi volesse approfondire.

 

11) Molti dei nostri lettori sono anche sviluppatori software web, quale è l’assunzione più importante per cambiare il proprio metodo di lavoro e renderlo Agile?

Non è necessario cambiare per il gusto di farlo, deve esserci una motivazione forte e chi muove i primi passi in agile parte dalla convinzione che qualcosa non stia funzionando nel modo in cui sviluppiamo software. I cambiamenti devono produrre un risultato concreto e apprezzabile altrimenti l’inerzia ci riporta sempre al punto di partenza.

E’ molto difficile mutare le nostre abitudini e oltre a tanta convinzione servono risultati concreti che ci spingono a non mollare e migliorare ancora.

Ad ogni modo l’assunzione più importante è provare a non progettare tutto all’inizio dandosi obiettivi per brevi cicli di sviluppo.

Invece di progettare tutto, dal design (wireframes e mockups) alle architetture (layers, classi e db) si può costruire una funzionalità alla volta e costruire in maniera emergente anche le architetture e l’interfaccia.

So che è molto difficile iniziare a farlo ma si può fare, noi ci stiamo riuscendo.