Il caso Nokia rappresenta un caso emblematico di successo nell’implementazione di una metodologia Agile: Scrum, su larga scala in tutta l’organizzazione. Ma rappresenta anche un caso emblematico di insuccesso nel essere Agile dal punto di vista del business e quindi come fare una trasformazione Agile affidandosi esclusivamente ad una metodologia non porta i benefici che l’Agility organizzativa crea.
Il caso
Alla conferenza Agile del 2009 Nokia appariva come il caso emblematico di una riuscita adozione Agile su vasta scala e tutti parlavano del Nokia test come una misura per comprendere il livello di implementazione Agile nell’intera organizzazione.
Nokia acquisì il sistema operativo Symbian nel 2008 e iniziò subito a svilupparlo per farlo diventare il cavallo di battaglia per entrare nel mondo degli smart phone. Nokia non aveva una mentalità Agile e tantomeno una struttura organizzativa Agile. Pensò che per essere competitiva doveva dotarsi di una metodologia Agile ed inserirla in azienda il più rapidamente possibile.
Trattandosi di sviluppo di software Nokia scelse la metodologia più immediatamente ovvia, Scrum, e la introdusse intensivamente in azienda. Quindi i manager si preoccuparono di verificare se l’implementazione stava riuscendo e quanto velocemente si stava diffondendo, così elaborarono il celebre Nokia test tutt’ora utilizzato dalle grandi società di consulenza. Il test si concentrava sui principi di scrum, gli eventi e gli artefatti e, attraverso survey periodiche, andava a verificare l’attinenza dei team alla metodologia. E da quel punto di vista era un successo.
Infatti i team di sviluppo adottarono favorevolmente e rapidamente scrum. Il loro problema era altrove. La struttura organizzativa di Nokia era rimasta tradizionale e vi era, come in tutte le organizzazioni convenzionali, una forte sconnessione tra il livello operativo e il livello manageriale, anche in termini di tool scelti e utilizzati. Inoltre gli sviluppatori ricevevano le user-stories da sviluppare senza una concreta connessione con i business outcomes e le metriche di produzione del software, non erano esplicite, o meglio, erano inesistenti.
Gli sviluppatori incontravano la maggior difficoltà sia durante la fase di sviluppo che in quella di deployment dovute alla rigidità e alle dimensioni dell’architettura di Symbian OS. Nokia mancò l’ingresso nel mercato degli smartphone perché la struttura organizzativa non era Agile. Nonostante il successo di implementazione della metodologia scrum, lo sviluppo non era connesso ai frequenti e critici feedback del mercato che stavano adottando i nuovi entranti e la struttura organizzativa non aveva assunto la caratteristica architettura di un ecosistema dove i team indipendentemente apportano il loro contributo end to end. Erano scollegati dal business.
L’insegnamento
Questo caso fa di Nokia l’emblema della differenza tra “essere” agile e “fare” agile, ovvero adottare una metodologia ed implementarla con successo in azienda. Il successo si misura dagli outcome, ovvero dall’impatto che abbiamo sui nostri clienti e questo è il primo criterio che ci dice se stiamo diventando Agile o lo stiamo solo facendo.
L’obiettivo overall di Nokia era lo sviluppo di Symbian OS per competere nel nascente mercato degli smartphone. Concentrandosi sulla metodologia Nokia ha orientato le persone sulla cosa meno importante: le metriche di output erano un successo, quelle di business un fallimento. La mancata connessione con il business e la mancanza di efficaci feedback diretti del mercato non permettevano ai teams e all’organizzazione di comprendere che stava avviandosi al fallimento. Anche se decantata come un successo di implementazione Agile at scale, in realtà scrum comportava un’ottimizzazione solo locale e solo parziale, supportate dalla visione ristretta di metriche orientate a misurare le attività al posto di avere una comprensione dell’impatto che il business avrebbe dovuto avere sul mercato.
Ecco quindi i principali fattori di insuccesso che Nokia ci insegna:
-
affidarsi ad una metodologia Agile non è garanzia di successo, probabilmente l’opposto è la modalità con cui le organizzazioni dicono di voler cambiare senza cambiare.
-
se il focus non è sul cliente finale e non si sta portando valore al cliente finale allora non si può parlare di Agile. Il primo fattore che ci dice se un’organizzazione è Agile è se sta portando valore al cliente.
-
se i team non sono composti da tutte le competenze e funzioni che portano valore al cliente e responsabili del processo end to end, fanno Agile ma non lo sono.
-
se la struttura organizzativa in funzione del fatto che i team configurati come al punto precedente non cambia, di nuovo l’organizzazione gioca a fare Agile ma non lo è.
Che risultati vuoi ottenere?
Il caso Nokia non è certo unico, basta guardarsi intorno per vedere diverse organizzazioni che hanno seguito lo stesso approccio di Nokia, che è poi quello tipico delle organizzazioni convenzionali: change management in stile top down in modalità waterfall. Risultato? I team che hanno adottato la metodologia performeranno meglio, saranno più veloci, ma non cambiando la struttura organizzativa e l’approccio culturale dopo un paio di anni di sforzi e costi non vedranno i benefici sperati.
Vedi anche l'articolo