L'Agile e il management

I parte: dal management tradizionale al Radical Managementdi

Introduzione: Agile per manager

In questa nuova serie di articoli affronteremo il tema dell’adozione delle metodologie all’interno dell’organizzazione dal punto di vista del management.

Lo scopo non è tanto quello di spiegare i concetti fondamentali dell’agilità o di Scrum e Kanban: per questo abbiamo già pubblicato in passato molti articoli i cui temi sono andati a confluire nel libro in progress Guida galattica per agilisti [1]. Desideriamo piuttosto mostrare quale sia l’impatto che questo tipo di cambiamento porta sia dal punto di vista organizzativo sia, e soprattutto, della mentalità necessarie per le persone coinvolte.

Vedremo infine come deve cambiare il ruolo del management — ne abbiamo già parlato qualche tempo fa [2] — e quali sono gli argomenti che è necessario tenere in considerazione per gestire in modo efficace questo processo di transizione.

Lo scopo di questa nuova serie è certamente ambizioso e, visto che parliamo di agilità, vorrei anche qui seguire un approccio simile a quello che tipicamente si tiene in un team agile: mi piacerebbe infatti gestire i contenuti di questa serie in modo flessibile e aperto al cambiamento, in modo da comporre la serie in modo iterativo e incrementale.

I contenuti della serie

Per il momento, in ogni caso, ho pensato di organizzare la serie in modo da affrontare i seguenti argomenti:

  • L’Agile dal punto di vista del management. La necessità di un cambio radicale: il Radical Management.
  • Evoluzione delle organizzazioni, una storia di complessità.
  • Agile Project Management (Flow Management).
  • Come evolve il ruolo del manager in una organizzazione agile. Il mestiere del Product Owner.
  • La relazione con i fornitori/clienti.
  • Come portare l’agilità in tutta l’organizzazione.

Per adesso vorrei partire seguendo questo schema, senza alcuna preclusione sulla base dei feedback che i lettori vorranno eventualmente farmi pervenire. Partiamo quindi in questa puntata con il presentare i concetti fondamentali dell’agilità senza però parlare di… Agile.

Parliamo infatti di Radical Management.

 

Il Radical Management: un modo alternativo di fare management

Un testo molto interessante per raccontare principi e valori dell’Agile alle persone del management è il libro The Leader’s Guide to Radical Management [3] di Stephen Denning; il libro è infatti noto nella comunità come un buon testo per raccontare l’Agile ai manager.

Nel suo libro, Denning non cita mai, o quasi mai, termini come come Agile, Scrum o Kanban, ma concentra invece l’attenzione su quello che lui chiama il Radical Management, in contrapposizione con il management “classico”. Denning lo descrive come un nuovo modo di intendere il lavoro all’interno delle organizzazioni che producono prodotti software, anche se la maggior parte dei principi esposti potrebbero essere applicati a molte delle aziende che fanno prodotti non IT.

Per chi ha già familiarità con i principi dell’Agile Manifesto, con le metodologie Scrum e Kanban, il libro rappresenta di fatto una rivisitazione di concetti già noti all’interno della comunità agile. Ma il punto importante del libro è che l’autore guida il lettore nella comprensione di principi e di valori indipendentemente dal fatto che tali principi e valori siano alla base della filosofia agile.

Nel testo, il Radical Management viene presentato come un modo completamente differente di intendere la gestione dell’azienda, basato su sette punti fondamentali che vediamo di seguito.

1. L’obiettivo del lavoro è la soddisfazione del cliente

Il primo punto da cui partire per rivoluzionare e migliorare il modo con cui fare management è passare da una gestione focalizzata sulla produzione di beni o servizi, a una in cui il focus di tutta l’organizzazione — non solo il marketing — è rivolto nel soddisfare il cliente finale e le sue necessità di business.

2. Fondare il lavoro su team autoorganizzati

Un gruppo di persone autoorganizzate, in cui ognuno partecipa alla buona riuscita del progetto, consente di ottenere risultati migliori, in termini di qualità finale, di soluzioni trovate, di reattività agli imprevisti.

In contesti complessi — come quelli in cui ci muoviamo ormai tutti i giorni nel mondo della produzione del software e non solo — spesso un team autonomo e autoorganizzato riesce a muoversi con maggior efficacia ed efficienza di uno organizzato secondo un modello gerarchico tradizionale, in cui c’è un capo/PM che comanda e controlla e in cui ogni decisione deve passare attraverso un articolato organigramma.

Avremo modo di parlare ulteriormente di questi concetti quando parleremo di complessità. Per chi fosse interessato ad approfondire il tema, consigliamo la lettura della prima parte del libro [1].

3. Organizzare il lavoro secondo un approccio iterativo e incrementale

Ad ogni rilascio il prodotto prende forma permettendo al team di raffinare la definizione del prodotto, tramite il feedback raccolto dal cliente che vede nascere il prodotto.

In questo modo il team si focalizza nel massimizzare l’interazione con il cliente/utente, in modo da apportare correzioni in corso d’opera prima che sia troppo tardi o troppo costoso.

Il feedback raccolto, oltre a permettere di migliorare quando già rilasciato, consente di aumentare le informazioni che saranno utili per realizzare le parti successive del prodotto [4].

4. Ogni iterazione deve rilasciare valore al cliente

Lavorare secondo un approccio iterativo e incrementale è realmente utile solo se ad ogni iterazione il team si impegna a rilasciare qualcosa di valore per l’utente finale. Solo in questo modo si riesce a creare un prodotto in modo incrementale e a ottenere feedback utile.

5. Il management deve incentivare la trasparenza

I punti precedenti — l’autoorganizzazione e il rilascio di valore in modo iterativo — si rendono possibili solo se il management crea le condizioni affinché ciò possa accadere in modo spontaneo. Fra queste condizioni, Denning suggerisce che il management incentivi la trasparenza in ogni forma: trasparenza fra le persone del team, trasparenza del team nei confronti del management, trasparenza del management nei confronti del team.

Muoversi all’interno di un clima di massima trasparenza permette di migliorare la collaborazione da parte di tutti, di favorire un approccio propositivo e non assertivo, di stimolare la contribuzione nel lavoro e di abilitare la creazione collaborativa. Tutto questo perché, nel Radical Management così come in Agile, si opera nella convinzione che il risultato del lavoro di un gruppo sia maggiore e migliore della somma delle attività slegate svolte dai singoli.

6. Il management deve incentivare il miglioramento continuo

Talvolta il management pone — e si pone — degli obiettivi stringenti definiti sulla base di metriche differenti: numero di funzionalità implementate o, peggio ancora, numero di punti realizzati se il team usa i punti per misurare la propria velocità [5], o livelli minimi di qualità, o tolleranza nel rispetto delle scadenze.

Spesso ci si rende conto che il rispetto di tali obiettivi non è realistico, sia per le metriche scelte che per i valori che ci si è prefissati, e questo porta il management a “stressare il sistema al suo massimo” per ottenere almeno una parte di quanto prefissato.

Purtroppo, nella maggior parte dei casi, questo clima di maggior stress porta a un evidente abbassamento della produttività: il rispetto degli obiettivi iniziali finisce per tramutarsi in onorevole “filosofia del buono abbastanza” o del “più di così non potevamo”. Nella pratica, un tale approccio comporta la creazione di un prodotto che contenga un numero “tollerabile” di difetti, in maniera da soddisfare in modo accettabile le aspettative del cliente.

Partendo dall’assunto che questa strategia non porta quasi mai ai risultati attesi, il Radical Management propone un approccio alternativo: invece di pensare agli obiettivi e stressare il sistema per raggiungerli, il suggerimento è quello di partire dalla definizione di un piano di miglioramento continuo, dove non è tanto importante la performance di per sé, ma il trend di miglioramento che deve essere deciso, costante, inarrestabile, privo di ripensamenti e di inversioni.

Una strategia di questo tipo, sebbene sia più realisticamente perseguibile, non è meno impegnativa e per certi versi “politicamente” scomoda: miglioramento continuo passa per l’analisi dei propri difetti e delle inefficienze, ovvero dal mettere in luce incapacità o difetti difficili da digerire.

Non è un caso che il management preferisca dare degli obiettivi e limitarsi a stressare il sistema affinché li raggiunga, piuttosto che mettere in luce pubblicamente — la famosa trasparenza del punto precedente — i propri difetti e le inefficienze per trovare delle soluzioni. Tutti, tutti i giorni, in tutte le occasioni possibili.

7. Usare la comunicazione interattiva

Per abilitare trasparenza (punto 5), favorire il miglioramento continuo (punto 6) e quindi rilasciare costantemente valore al cliente (punto 4), gli attori coinvolti nella realizzazione di un prodotto devono svolgere diverse attività. E una delle cose più importanti che devono fare è parlarsi in modo efficace, diretto, autentico.

Si dovrebbero quindi rimuovere tutte quelle barriere che limitino il fluire delle informazioni. Denning propone il termine di comunicazione interattiva basata sull’ascolto attivo, sullo scambio bidirezionale di informazioni e commenti, in cui la sincerità — una franchezza senza ipocrisie, ma rispettosa e gentile — sia sempre alla base di ogni scambio. Nella raccolta dei requisiti, per esempio, sono da evitare forme gergali o descrizioni del lavoro tecnicistiche, a cui si dovrebbero preferire forme narrative — raccontare storie, storytelling — che meglio esprimono le necessità dell’utente finale.

 

Le “fonti” del Radical Management: la Toyota Way

Quando si parla di Radical Management si finisce spesso — e anche Denning lo fa — per ispirarsi al lavoro iniziato in Toyota da Taiichi Ohno negli anni Cinquanta del secolo scorso e di fatto mai terminato.

Nel 2001 l’azienda, ormai molto differente da quella che era uscita dalla crisi della seconda guerra mondiale, fondava il proprio modello sullo schema raffigurato dall’immagine in figura 1.

Figura 1 – Lo schema concettuale del modello Toyota.

Figura 1 – Lo schema concettuale del modello Toyota.

 

Toyota si poggia su due pilastri fondamentali: il continuous improvement e il rispetto per le persone; questi due pilastri a loro volta si poggiano su fondamenta che sono lo spirito della sfida (volontà di lanciare e accettare sempre nuove sfide), una inarrestabile ricerca per il miglioramento (kaisan o kaizen) e, forse uno dei più importanti aspetti della filosofia giapponese, il gechi genbutsu (vai di persona a vedere cosa succede sul mercato), senza dimenticare il rispetto  (per le persone, per i collaboratori, gli stakeholder, i partner coinvolti, ma  anche la società esterna, tutti), e il lavoro in team.

Molto importante il passaggio che si trova nel  documento interno di Toyota dedicato al Way relativamente al concetto di sfida:

  • Accettiamo le sfide con uno spirito creativo e il coraggio di realizzare i nostri sogni senza perdere l’intraprendenza o l’energia.  Affrontiamo il lavoro con vigore, ottimismo e una sincera convinzione del valore del nostro contributo. [...]
    Ci sforziamo di decidere il nostro destino.
    Agiamo con indipendenza, fidandoci delle nostre capacità. Accettiamo la responsabilità del nostro agire e il dovere di affinare le competenze che ci permettono di produrre valore aggiunto.

Queste parole assumono un significato ancora più importante se inserite nel contesto storico in cui T. Ohno si trovò a lavorare (un paese distrutto dopo due bombe atomiche, la crisi economica innestata dopo la seconda guerra mondiale). Ohno raccolse la sfida con coraggio e spirito creativo, affrontando una dopo l'altra le difficoltà che gli si paravano difronte.

In una celebre intervista David Sutherland, uno dei padri dell’agilità moderna, racconta come molti dei manager intervistati erano in grado di comprendere la maggior parte delle pratiche alla base del Toyota Production System (TPS), mentre erano più in difficoltà nel comprendere a fondo la filosofia che vi è alla base, la cosiddetta “Toyota Way”, da cui prende lo spunto un interessante libro [6].

Il TPS, raccontato nell’altro importante libro The machine that changed the world [7], è di fatto compatibile con le assunzioni del management tradizionale: eliminare gli sprechi dal processo di lavorazione, cosa che può essere perseguita dal management senza alcun cambiamento radicale del comportamento. Seguire completamente l’esempio di Toyota, invece, richiede un cambiamento radicale di mentalità rispetto al modo di pensare del management tradizionale.

Quando l’implementazione dell’approccio di Toyota si limita semplicemente nell’eliminazione degli sprechi, i risultati che si ottengono sono in genere differenti e spesso modesti rispetto a quello che si trova nel Toyota Way. In gergo si fa riferimento ai Cargo Cult [8], quando si “scimmiottano” dei comportamenti esteriori senza però averne compreso in profondità le motivazioni, il senso, i valori che ne costituiscono il fondamento [9].

Senza il rispetto per le persone, tutto il carico di lavoro relativo al processo di miglioramento ricade sulle spalle delle persone: sono i soli incaricati o impegnati nella ricerca dei difetti e delle loro cause. In questo caso i tempi si dilatano, le soluzioni sono trovate lontano nel tempo e nello spazio dai problemi e sono spesso frutto della visione di un tipo di persone… i manager appunto.

Mutuato dal Toyota Way il rispetto per le persone diviene così il pilastro più importante di tutto il pensiero del Radical Management, più dell’ottimizzazione del sistema; è la condizione abilitante e promotrice del processo di miglioramento continuo.

Miglioramento continuo

Miglioramento continuo vuol dire quindi responsabilizzare i lavoratori e permettere loro di agire per identificare i problemi e le loro cause; in questo modo l’organizzazione migliora più rapidamente e meglio di quelle tradizionali, dove il peso di questo processo di diagnosi e prognosi è spesso a carico solamente dei manager, i soli autorizzati a valutare, analizzare, decidere, risolvere.

Spostando queste responsabilità verso il basso, l’obiettivo è quello di promuovere la soluzione dei problemi — non tutti, ma certamente quelli legati alla produzione — localmente al punto in cui si verificano. Probabilmente questa è la differenza più importante rispetto al management tradizionale.

Non deve meravigliare quindi come la maggior parte del management occidentale abbia compreso e accettato i principi raccolti nel primo libro, mentre abbia fatto fatica a comprendere il messaggio alla base del libro Toyota Way; probabilmente è anche questo il motivo per il quale negli anni Ottanta il tentativo di implementare il Lean da parte del management di General Motors portò a quello che poi è diventato noto come Lean di Chicago: di fatto un mix fra alcuni principi Toyota corretti e tanto management tradizionale, risultante in un vero e proprio “Cargo Cult” nell’ambito nella produzione automotive.

 

Dal Radical Management all’Agile Manifesto

La maggior parte dei suggerimenti qui riportati sono un mix dei principi del manifesto agile [10] e della filosofia Lean messa a punto da Taiichi Ohno all’interno di Toyota nella seconda metà del secolo scorso. La somiglianza con i principi dell’Agile Manifesto in questo senso è strettissima.

I principi su cui si basa una metodologia agile che segua i punti indicati dall’Agile Manifesto sono solo quattro:

  • Le persone e le interazioni sono più importanti dei processi e degli strumenti, ossia le relazioni e la comunicazione tra gli attori di un progetto software sono la miglior risorsa del progetto.
  • È più importante avere software funzionante — ossia un prodotto di qualità che soddisfi i bisogni utente — che documentazione. Bisogna rilasciare nuove versioni del software ad intervalli frequenti, e bisogna mantenere il codice semplice e avanzato tecnicamente, riducendo la documentazione al minimo indispensabile.
  • Collaborare con i clienti oltre che rispettare il contratto: la collaborazione diretta offre risultati migliori dei rapporti contrattuali.
  • Essere pronti a rispondere ai cambiamenti oltre che seguire una pianificazione: pertanto il team di sviluppo dovrebbe essere pronto, in ogni momento, a modificare le priorità di lavoro nel rispetto dell’obiettivo finale.

In sintesi, l’Agile Manifesto, sottolinea l’importanza dei su citati principi fermo restando il valore di processi, strumenti, documentazione, contratti e pianificazione.

Da questo derivano i principi agili fedelmente riportati dal documento ufficiale [10]:

  • La nostra massima priorità è soddisfare il cliente rilasciando software di valore, fin da subito e in maniera continua.
  • Accogliamo i cambiamenti nei requisiti, anche a stadi avanzati dello sviluppo.
  • I processi agili sfruttano il cambiamento a favore del vantaggio competitivo del cliente.
  • Consegniamo frequentemente software funzionante, con cadenza variabile da un paio di settimane a un paio di mesi, preferendo i periodi brevi.
  • Committenti e sviluppatori devono lavorare insieme quotidianamente per tutta la durata del progetto.
  • Fondiamo i progetti su individui motivati.
  • Diamo loro l’ambiente e il supporto di cui hanno bisogno e confidiamo nella loro capacità di portare il lavoro a termine.
  • Una conversazione faccia a faccia è il modo più efficiente e più efficace per comunicare con il team e all’interno del team.
  • Il software funzionante è il principale metro di misura di progresso.
  • I processi agili promuovono uno sviluppo sostenibile.
  • Gli sponsor, gli sviluppatori e gli utenti dovrebbero essere in grado di mantenere indefinitamente un ritmo costante.
  • La continua attenzione all’eccellenza tecnica e alla buona progettazione esaltano l’agilità.
  • La semplicità — l’arte di massimizzare la quantità di lavoro non svolto — è essenziale.
  • Le architetture, i requisiti e la progettazione migliori emergono da team che si autoorganizzano.
  • A intervalli regolari il team riflette su come diventare più efficace, dopodiché regola e adatta il proprio comportamento di conseguenza.

 

Conclusione

In questo primo articolo abbiamo introdotto il concetto di Radical Management, il suo significato e i benefici che si possono trarre se si passa da un management tradizionale a uno innovativo (radicale), presentando i sette punti che lo descrivono e che sono ampiamente discussi nel testo che definisce il management radicale [3].

Il mese prossimo proveremo a vedere alcuni suggerimenti per implementare il Radical Management all’interno delle organizzazioni.

 

Riferimenti

[1] Guida galattica per agilisti

http://www.guidagalatticaperagilisti.com

 

[2] Stefano Leli – Giovanni Puliti, Come evolve la figura del Project Manager in un contesto agile?, MokaByte 208, luglio 2015

http://www.mokabyte.it/2015/08/pmagile/

 

[3] Stephen Denning, The Leader’s Guide to Radical Management: Reinventing the Workplace for the 21st Century, Jossey-Bass, 2010

http://www.stevedenning.com/site/Default.aspx

 

[4] Giovanni Puliti, Verso l‘Agile – I parte: L'importanza dell'apprendimento, MokaByte 188, ottobre 2013

http://www.mokabyte.it/2013/10/versoagile-1/

 

[5] Giovanni Puliti, Guida Galattica per scrummers – VIII parte: Le stime.Che cosa sono, come e quando farle in un progetto agile, MokaByte

http://www.mokabyte.it/2014/05/guidascrummers-8/

 

[6] The Toyota Way

http://www.toyota-way.it

 

[7] Womack J.P. – Jones D.T. – Roos D., “The Machine That Changed the World: The Story of Lean Production”, Harper Business, 1991 (trad. it. “La macchina che ha cambiato il mondo”, Rizzoli 1999)

 

[8] La voce “Cargo cult” su Wikipedia

https://en.wikipedia.org/wiki/Cargo_cult

 

[9] Giovanni Puliti, Verso l’Agile – II parte: Miti, fatti e pianificazione, MokaByte 189, novembre 2013

http://www.mokabyte.it/2013/11/versoagile-2/

 

[10] Agile Manifesto

http://www.agilemanifesto.org/iso/it

http://www.agilemanifesto.org/iso/it/principles.html

 

 

Condividi

Pubblicato nel numero
218 giugno 2016
Giovanni Puliti lavora come consulente nel settore dell’IT da oltre 20 anni. Nel 1996, insieme ad altri collaboratori crea MokaByte, la prima rivista italiana web dedicata a Java. Da allora ha svolto attività di formazione e consulenza su tecnologie JavaEE. Autore di numerosi articoli pubblicate sia su MokaByte.it che su…
Articoli nella stessa serie
Ti potrebbe interessare anche