La mentalità Agile
Tempo di lettura: 10 minuti
Nel cercare di applicare una metodologia Agile, non sempre si è in grado di ottenere i risultati sperati.
Spesso si spera che l’utilizzo di software come Trello, Jira, Asana, ecc… siano la soluzione a tutti i problemi di gestione dei progetti e in essi si ripongono molte speranze da parte della funzione amministrative delle diverse organizzazioni. Utilizzare un buon applicativo che permetta una corretta integrazione con i processi aziendali e sia facile da usare anche per persone non avvezze a pratiche di Project Management è sicuramente qualcosa di utile, ma non è tutto. Fare in modo che approcci come Scrum o XP prendano piede in azienda non è un aspetto da sottovalutare quando si vogliono introdurre queste metodologie.
In questo articolo indagheremo alcuni comportamenti che favoriscono o meno i processi e influenzano direttamente la buona riuscita di un progetto che si vuole svolgere secondo i framework tipici di Agile. Per poter comprendere al meglio quanto verrà espresso successivamente, è bene avere consapevolezza del fatto che non è rimuovendo tutti gli ostacoli che Agile funziona, ma è lavorando giorno per giorno sulla mentalità di ogni individuo che si cambia il suo modo di affrontare le sfide che gli si pongono di fronte.
Un’ultima precisazione che risulta doveroso fare prima di iniziare con questa (comunque incompleta) lista è che i comportamenti che verranno elencati non si devono ritenere dannosi solamente per le metodologie Agile ma possono compromettere la riuscita di un qualunque progetto svolto anche secondo modalità tradizionali. Questi, infatti, sono atteggiamenti che le persone possono o meno mostrare indipendentemente dalle tecniche di gestione dei progetti che si vogliono utilizzare per svolgere al meglio i compiti affidati al team di sviluppo.
Comportamenti che favoriscono lo sviluppo Agile
La teoria, da sola, costituisce un buon punto di partenza per l’applicazione di metodologie Agile, ma non è tutto. Basarsi eccessivamente su manuali trascurando le persone, i loro comportamenti, i modi di porsi e confrontarsi con i loro vicini non risulta un’idea vincente. Ogni framework Agile ha alla base l’idea che quelle fornite sono indicazioni, best practices che possono essere introdotte per ottenere buoni risultati ma che devono essere poi calate e adattate alle realtà nelle quali si opera per ottenere il massimo possibile. L’importante è che si stimolino le persone ad utilizzare il buon senso per applicare con criterio quando appena detto.
Uno dei primi aspetti da chiarire nella mente delle persone che vogliono applicare queste metodologie è che fare Agile non coincide con essere Agile. Non è definendo bene un Product backlog, nominando un Product owner, interpellando uno Scrum master, utilizzando tecniche di retrospettiva, ecc… che si sviluppa una mentalità Agile. L’uso delle tecniche è importante ma ancora più importante è prendere consapevolezza di ciò che si sta facendo e non applicarlo in maniera cieca. La conoscenza della metodologia deve diventare qualcosa che viene interiorizzato dalle persone, in modo che esse possano utilizzarla e integrarla al meglio nei processi e nelle mansioni che normalmente svolgono.
Questa consapevolezza deriva non solo da aspetti prettamente teorici ma anche dalla pratica che permette di capire come possano effettivamente essere utili determinate pratiche, specifici atteggiamenti e alcuni suggerimenti forniti dai libri. In tutto ciò, un momento molto importante è quello del Retrospective meeting che permette al team di fermarsi e riflettere sul suo operato e quindi di migliorarsi. Questa riunione non deve essere vissuta come una perdita di tempo ma come un momento di crescita sia collettivo che personale di ogni membro del gruppo durante il quale si prende coscienza di quanto realizzato fino a quel momento.
Un aspetto da sviluppare è, invece, quello dell’empowerment. Con questo termine si indica la coesione di gruppo e la consapevolezza che è tutto il team a vincere o a perdere, a fare un errore o svolgere tutto in maniera corretta. Ogni sbaglio non deve essere affrontato con la volontà di individuare il colpevole ma visto come una possibilità di miglioramento.
Questo sentimento di squadra può nascere spontaneamente tra individui di pari livello ma può anche essere stimolato da figure “apicali” come il Product owner o lo Scrum master. L’importante è che l’empowerment cresca con il numero di iterazioni, in modo che le persone possano fidarsi le une delle altre e quindi anche aiutarsi vicendevolmente nell’evitare gli errori o quantomeno limitarli nel singolo segmento di progetto nel quale si trovano.
Un ultimo aspetto di fondamentale importanza è il ruolo giocato dall’organizzazione nell’introdurre prima e implementare poi una metodologia Agile. La realtà nella quale ci si trova ad operare deve essere, infatti, pronta ad accettare il cambiamento che framework come quelli appena presentati possono portare. Mai come in periodi come quelli che stiamo vivendo da una decina di anni si percepisce un grande fermento e una continua turbolenza nel modo di lavorare e di vivere; affrontare queste sfide rimanendo inerti o comunque con un approccio uguale a quello che si aveva ieri non è sicuramente la modalità corretta, se si vuole sviluppare qualcosa che possa crescere e sopravvivere a lungo.
Tutto questo però non è standardizzabile, non esiste una ricetta uguale per tutti in quanto ogni ecosistema organizzativo risulta diverso da un altro e quindi anche stimoli apparentemente identici possono portare forti differenze nei risultati ottenuti. Essendo che, come afferma Larman, ogni organizzazione si struttura implicitamente in modo da resistere al cambiamento dello status quo, sarà proprio dall’organizzazione stessa (ed in particolare dai vertici) che dovrà partire una forte volontà di modifica strutturale.
L’Agile è sicuramente un qualcosa di particolarmente distruttivo per aziende strutturate in maniera tradizionale ma ciò non vuol dire che non possa prendere piede o che debba sostituire completamente tecniche già implementate e funzionanti. Non è necessario stravolgere tutto per portare modifiche alla struttura ma si può iniziare affrontando piccoli problemi, implementando nuove metodologie a progetti di rilevanza limitata o in ambiti particolari. Come detto nell’introduzione, progetti e processi sono due realtà differenti che convivono e collaborano continuamente ma non è necessario che affrontino i cambiamenti allo stesso modo o nello stesso tempo. Certo è che, quando si deciderà di implementare queste pratiche in maniera rilevante, dovranno essere ridotti al minimo gli attriti “burocratici” e dovranno essere messe a disposizione tutte le forze necessarie.
Comportamenti che minano lo sviluppo Agile
In antitesi a quanto appena visto, vengono indicati alcuni comportamenti, alcune modalità di agire e di pensare che possono minare fortemente la buona riuscita di un progetto Agile.
Il primo errore che mettiamo in evidenza è quello di modificare i processi tradizionali in modo che possano adattarsi alla metodologia Agile. In questo caso, l’errore è di dare un nome sbagliato alle cose portando a snaturare elementi caratteristici di questo nuovo mondo. Un tasto particolarmente dolente è quello delle iterazioni. Esse devono essere limitate nel tempo in maniera definita a priori e sempre uguale e devono fornire un deliverable che possa essere utilizzato dal cliente, una parte di codice che implementa alcune funzionalità, un modello 3D del gruppo che andrà a produrre, ecc… Quando invece le iterazioni sono usate solo come intervallo di tempo tra due riunioni consecutive con il cliente, ecco che il tutto perde di significato. In questo caso l’obiettivo non sarà più quello di fornire qualcosa che generi valore per il cliente ma qualcosa che verrà unito ad altro che però non è ancora stato sviluppato e in assenza del quale nulla risulta funzionante.
Un secondo aspetto importante è la necessità di selezionare le persone giuste. Proprio perché l’obiettivo di un’iterazione è fornire qualcosa che generi valore per il cliente, importante è il coinvolgimento di tutte le figure utili alla realizzazione di ciò. Il team di progetto deve avere al suo interno tutte le competenze necessarie per realizzare quanto richiesto e ogni membro del gruppo è tenuto a prendere parte a tutte le riunioni. Se uno di questi due aspetti venisse a mancare, non si riuscirebbe ad effettuare quel cambio di mentalità auspicato e soprattutto non si creerebbe nulla di utile per il cliente.
Terzo punto è la consapevolezza del ruolo di ogni individuo all’interno dell’organizzazione. Figure come quella di Scrum master e Product owner devono essere istituzionalizzate e non possono essere affidate con leggerezza. Ad esempio, il primo può, in apparenza, sembrare un ruolo facilmente assegnabile ad un Project Manager ma così non è. I due hanno compiti molto differenti e modalità di approcciarsi al lavoro e al gruppo di progetto particolarmente diverse. Come per il ruolo di PM più “tradizionale” è necessaria una certa formazione condita da certificazioni, attestati, ecc…, anche la persona individuata per assumere il ruolo di Scrum master deve essere formata in maniera attenta e soprattutto essere selezionata come individuo in grado di acquisire quelle specifiche competenze.
Un altro momento sacro per le metodologie Agile sono gli incontri. Questi devono essere gestiti in modo da risultare efficaci. In particolare, le persone coinvolte in questi meeting devono avere potere decisionale, onde evitare che inizi un continuo quanto inconcludente passaggio di responsabilità. Tutti gli individui interessati al progetto devono inoltre essere coinvolti e devono arrivare preparati ed essere in grado di parlare in maniera chiara, esponendo i dubbi e le idee senza paura di essere giudicati. Tra quelli evidenziati, l’incontro più critico per grado di novità è lo Stand-up meeting, che ha bisogno di accortezze maggiori, come la puntualità di tutti i membri del gruppo (è di breve durata e arrivare in ritardo comprometterebbe tutta l’organizzazione), la comprensione del senso dell’incontro (serve a pianificare la giornata e ricapitolare quanto svolto nelle 24 ore precedenti) e la corretta assegnazione delle User stories che devono essere scelte in base alla priorità e non alla congenialità di una o dell’altra.
In tutto questo, un aspetto che potrebbe favorire lo sviluppo di gruppi affiatati e responsabili è l’avere una visione completa del progetto e non chiusa a compartimenti stagni o comunque limitata da ruoli istituzionali. Questi impedimenti, infatti, porterebbero le persone a fare assunzioni su basi sbagliate e potrebbero avere ripercussioni deleterie per tutto l’avanzamento del progetto.
Un problema che si verifica spesso oggi è la percezione di avere poco tempo a disposizione. Ciò porta le persone a correre, curare poco i dettagli, non porre attenzione alle cose, mettere ansia ai collaboratori che hanno intorno e non rilassarsi mai. In progetti svolti con approccio Agile, bisogna ricordare che non si è soli, anzi, si può contare su un gruppo che vince e perde, ma soprattutto gioca insieme. Avere comportamenti che sviluppano ansia negli altri può essere deleterio in primis per sé, ma anche per le persone che ci circondano; per questo motivo risulta importante mitigare i propri comportamenti sapendo che sicuramente il tempo è una variabile fondamentale da rispettare, ma che prima di tutto è la qualità del prodotto che deve risultare vincente e fornire valore per tutto il gruppo.
Una caratteristica che metodologie tradizionali e Agile hanno in completa opposizione è quella relativa alla chiusura dei requisiti. Il Product backlog è un artefatto vivente, viene continuamente aggiornato ad ogni iterazione e si arricchisce continuamente di funzionalità richieste dal cliente o suggerite dal gruppo di progetto. In questo la differenza con progetti tradizionali è lampante infatti, in questi ultimi, una volta definito l’ambito del progetto si parte a testa bassa. È questa differenza che rende attuali i framework Agile in tempi così turbolenti.
Ultimo atteggiamento che si deve assolutamente evitare è quello sintetizzato dalla frase “non è il mio lavoro!”. Questa è potenzialmente una delle frasi più distruttive che si possano sentire per qualsiasi modalità con cui si affronta un progetto, in particolare per quelle Agile. Il team di sviluppo è un gruppo coeso, unito, che condivide vittorie e fallimenti e nessuno dei membri può e deve permettersi di avere questo tipo di pensiero. In particolare, le figure più rilevanti del gruppo devono esprimere la loro leadership mettendosi in gioco per primi, coinvolgendo e convincendo gli altri ad avere approcci proattivi; devono essere loro i primi a portare un cambiamento di mentalità all’interno del gruppo.
Conclusioni
Riuscire ad applicare correttamente le pratiche Agile non è solo questione di strumenti e di tecniche ma anche (e soprattutto) di selezionare le persone giuste, con le competenze tecniche adeguate a completare uno Scrum Team ma anche quelle corrette a livello relazione, comunicativo e di mente aperta. La prima sfida nell’implementazione di pratiche agili, quindi, esula da aspetti tecnici e richiede un importante lavoro dal punto di vista psicologico.
