L’Agile e il management

II parte: Radical Management all’operadi

Un modo nuovo di intendere il management

Come dicevamo nella prima puntata della serie, in questi articoli vogliamo guadare le tematiche agili dal punto di vista del management di una azienda/organizzazione. Abbiamo a più riprese e in diverse forme trattato i concetti fondamentali delle metodologie agili [1] ma qui ci interessa guardare al modo in cui deve cambiare la mentalità e il ruolo del management [2].

Ma anche noi dobbiamo cambiare prospettiva e adattarci dinamicamente alle situazioni e, in questo senso, gli articoli che state leggendo nella serie sono un po’ diversi rispetto al solito. Infatti, da sempre sulle colonne di MokaByte abbiamo puntato a pubblicare contenuti frutto di quel mix efficace di teoria e personali esperienze dirette sul campo.

In questa miniserie invece stiamo provando un approccio differente: dopo aver sperimentato sul campo nell’ambito di varie attività di consulenza e coaching strategie e tecniche per portare Agile nelle organizzazioni, abbiamo trovato che il libro di Denning [3] è molto in linea con il pensiero mio e dei miei colleghi. Per questo mi è sembrato corretto dare il giusto spazio all’autore e al suo libro, riportando i passaggi più in linea con quanto ho avuto modo di provare direttamente.

Il Radical Management secondo Denning

Nella puntata precedente abbiamo visto come nel suo The Leader’s Guide to Radical Management, Stephen Denning non citi quasi mai termini come come Agile, Scrum o Kanban, ma si concentri su quello che lui chiama il Radical Management vale a dire un nuovo modo di intendere il lavoro all’interno delle organizzazioni

Nel testo il Radical Management viene presentato come un modo completamente differente di intendere la gestione dell’azienda, basato su 7 punti fondamentali:

  1. l’obiettivo del lavoro è la soddisfazione del cliente;
  2. fondare il lavoro su team autoorganizzati;
  3. organizzare il lavoro secondo un approccio iterativo e incrementale;
  4. ogni iterazione deve rilasciare valore al cliente;
  5. il management deve incentivare la trasparenza;
  6. il management deve incentivare il miglioramento continuo;
  7. usare la comunicazione interattiva.

Nella puntata precedente abbiamo proprio visto nel dettaglio il significato di questi sette punti; e quindi rimandiamo a quell’articolo il lettore che volesse approfondire l’argomento.

Strategie per implementare i 7 punti

Nella seconda parte del suo libro, Denning propone una serie di strategie o pratiche, utili a perseguire i 7 punti presentati precedentemente. Per chi fosse particolarmente interessato a questa parte consiglio vivamente di leggersi il libro per intero, dato che riporta molti consigli e casi piuttosto interessanti.

Riporto in ogni caso qui di seguito alcune di queste pratiche, che ho trovato particolarmente pertinenti al discorso che stiamo pubblicando in questa serie di articoli.

 

Pratiche per focalizzare il lavoro sulla soddisfazione del cliente

Il focus principale di una azienda deve essere quello di avere clienti soddisfatti del prodotto/servizio che essa fornisce. Vediamo di seguito alcune pratiche che consentono di mettere in pratica questo punto.

Clienti primari

Per costruire un buon prodotto si dovrebbe sempre partire dall’identificare i bisogni dell’utente che il prodotto deve risolvere. In tal senso quindi è necessario, fra le prime cose da fare, descrivere bene gli utenti del sistema: per questo è importante identificare per prima cosa i clienti “primari” ossia quelli che esprimono i bisogni principali che il prodotto in questione dovrà soddisfare.

Simple is better

Partire sempre a sviluppare la soluzione più semplice che possa soddisfare tali bisogni; provare con più soluzioni alternative, sperimentarne di non convenzionali. Provare quelle soluzioni che soddisfano più requisiti con meno cose: evitare di fare cose inutili o eccessivamente complicate. Evitare di avere un approccio meccanicistico.

Last responsible moment

Rimandare le decisioni fino a che non si può farne a meno, in modo da avere il maggior numero di informazioni possibili per poter decidere al meglio (possibile). In Toyota, nell’applicazione del Toyota Production System, gli ingegneri trascorrono moltissimo tempo a valutare e studiare le possibili alternative, prima di prendere una decisione finale.

Focus on people, not things

Cercare sempre di dare risalto alle persone, facendo leva sulle loro capacità e sulle loro necessità, non tanto sugli oggetti che si devono produrre o su quelli necessari per produrli.

 

Pratiche per agevolare la creazione di team autoorganizzati

La nascita di gruppi di lavoro che si autoorganizzano e si prendono in carico delle responsabilità in maniera consapevole una delle chiavi per migliorare produttività e sostenibilità del processo. Alcuni fattori sono fondamentali per agevolare team autoorganizzati

Obiettivi

Definire un obiettivo del lavoro che sia avvincente, di valore e in cui sia chiaro il beneficio che porta all’utente finale.

Comunicazione

Comunicare costantemente e appassionatamente il valore del lavoro che si sta facendo.

Possibilità di decisione

Dare potere decisionale al team, ma sempre in funzione di quanto il team accetta le responsabilità che ne derivano.

Bilanciare delega ed emancipazione

Bilanciare il processo di delegaempowerment, una parola che va molto di moda — con la capacità del team di trovare la propria strada e di emanciparsi. Trasferire potere spesso finisce per creare dei cloni della figura del capo, mentre è molto importante che il gruppo cresca in modo autonomo, innovativo, rivoluzionario. Molto interessante in tal senso il libro Turn the ship around, in cui si affronta, fra le altre cose, proprio questo tema [4].

In ogni momento provare a creare nuove tecniche e strumenti per sostenere l’autorganizzazione del team. È utile nel processo di empowerment prima e di emancipazione poi, supportare il team tramite un coach che rafforzi l’implementazione delle pratiche.

 

Pratiche per impostare il lavoro in maniera iterativa

Si dice spesso che uno dei vantaggi di Agile è l’impostazione di un processo iterativo e incrementale. Ma il passaggio a una strategia di questo tipo non sempre è semplice. Ecco alcuni consigli per semplificare il passaggio.

Priorità

Prioritarizzare il lavoro in modo da completare prima le attività di maggior valore per l’utente. Far partecipare il cliente o un suo rappresentante all’attività di ordinamento per valore. Dare priorità alle cose di valore e poi a quelle per le quali si hanno abbastanza informazioni per poter procedere al loro completamento. Inserire in ogni iterazione solo il lavoro che non può essere rimandato, ossia che utente desidera a breve e che non sia sostituibile con altre attività di maggior valore per utente.

Obiettivo per iterazione

Definire il goal di ogni iterazione: anche se si tratta sostanzialmente di “fare delle cose”, ogni iterazione dovrebbe comunque far comprendere il motivo per cui si fanno quelle cose.

Elenco di attività da completare

Il lavoro all’interno delle iterazioni dovrebbe essere definito come un elenco di attività; ogni attività dovrebbe esprimere bene a quale utente si rivolge, quale beneficio porta, espresso per esempio in termini di un cambio di comportamento o di una nuova funzionalità di indubbia utilità o necessità. Per ogni attività specificare chiaramente i criteri di accettazione, ossia i criteri con i quali si potrà capire se l’attività è stata effetticamente completata.

Linguaggio comprensibile per i requisiti

I requisiti devono essere definiti e catalogati in unità piccole, semplici, facilmente comprensibili senza ricorrere a linguaggio tecnico o gergale. Questo ne consente la comprensione sia alle persone del team che ai clienti/utenti o ai loro rappresentanti.

Attività indipendenti

Le attività dovrebbero essere il più possibile indipendenti fra loro (in modo da facilitare l’ordinamento o il riordinamento).

Discutere le attività da fare nell’iterazione

Ogni iterazione dovrebbe sempre iniziare prima di tutto con la discussione delle attività da svolgere all’interno dell’iterazione. Dopo tale accordo, si dovrebbe cercare di mantenere stabile il contenuto dell’iterazione stessa. Le funzionalità presentate all’inizio dell’iterazione devono essere pronte per la lavorazione.

Stimare le attività da fare nell’iterazione

Il team deve valutare e quindi stimare tali attività in modo da decidere quante prenderne in lavorazione, in base alle proprie capacità.

Rimuovere gli impedimenti

Durante l’iterazione aiutare il gruppo di rimuovere gli impedimenti o metterlo nelle reali condizioni di farlo da sé.

Misurare i progressi

Misurare il progresso di ogni iterazione con il numero di cose fatte e funzionanti, eventualmente “pesato” in funzione del valore delle varie attività.

Demo e retrospettiva

Ogni iterazione dovrebbe sempre concludersi con la valutazione del lavoro completato (demo del lavoro fatto) e del come si è lavorato (retrospettiva di team). Definire sempre un piano di miglioramento per l’iterazione successiva.

 

Pratiche per favorire la trasparenza

La trasparenza è un valore fondamentale nel Radical Management così come nelle metodologie Lean/Agile. La trasparenza si declina all’interno del team, da parte del team nei confronti del management e da parte del management verso il team.

Trasparenza all’interno del team

Lasciare al team la decisione su quante cose potranno essere svolte nella prossima iterazione. Per questo è utile che, ad ogni iterazione, il team valuti retrospettivamente la propria capacità di lavorazione.

Utilizzare information radiator visuali, ossia lavagne, poster, e altri strumenti informativi, condivisi e di facile comprensione.

Trasparenza del team nei confronti del management

Al termine di ogni iterazione, il team si impegna per rilasciare “manufatti” di valore per il cliente finale.

Identificare e comunicare quotidianamente tutti gli impedimenti che impediscono al team di sviluppo di svolgere il proprio lavoro, sia che si tratti di impedimenti interni (per esempio, non si sanno fare delle cose) che esterni (ci sono degli imprevisti che bloccano, occorre attendere una risposta che ancora non arriva).

Trasparenza del management nei confronti del team

Comunicare e condividere le priorità prima che lo sprint abbia inizio.

Go and see: non restare nel proprio ufficio ma andare sempre a visitare il team per vedere cosa succede sul luogo del lavoro così come verificare sempre cosa accade sul mercato.

Cliente/utente e team dovrebbero essere a stretto contatto. Il management non dovrebbe dividerli.

Agire concretamente per rimuovere gli impedimenti.

 

Pratiche per agevolare l’automiglioramento continuo

Un importante aspetto è quello del continuous self-improvement: le attività svolte devono portare anche a un continuo miglioramento delle competenze di chi prende parte al progetto. Una serie di pratiche che favoriscono tale miglioramento riportate di seguito.

  • Non reprimere l’iniziativa e dare sempre l’opportunità di eccellere.
  • Identificare gli obiettivi/bisogni del team e lavorare per allinearli con quelli dell’organizzazione.
  • Essere consapevoli in modo realistico della capacità di lavorazione del team.
  • Agire per liberare gli impedimenti per il team.
  • Condividere conoscenze e strumenti.
  • Favorire la creazione di comunità cross team focalizzate sullo scambio di esperienze e tecniche specifiche (le cosiddette Community of Practice).
  • Essere sempre pronti alle nuove idee.
  • Appoggiare il desiderio del miglioramento continuo.

 

Pratiche per abilitare la comunicazione interattiva

Descrivere il prodotto in modo narrativo ponendo l’accento sull’interazione fra il prodotto e l’utente. Strumenti come lo storytelling o le User Stories risultano molto utili. Ma non bisogna fermarsi al prodotto: è bene usare le storie e la narrrazione anche per descrivere i bisogni utente e ispirare il gruppo nella ricerca di soluzioni.

 

Implementare il Radical Change Management

Anche la gestione del cambiamento può essere affrontata con un approccio radicale: è il Radical Change Management. A tale scopo, risultano molto utili i seguenti consigli.

  • Adattare i concetti e i principi del Radical Management al proprio contesto.
  • Investire e rafforzare un core team che faccia da guida per promuovere il cambiamento.
  • Partire da un contesto favorevole sicuro: un team favorevole a sperimentare le novità, progetto pilota, un cliente disponibile e aperto al cambiamento, uno sponsor di valore che aiuti il team.
  • Definire una bozza iniziale del piano, ma poi fare in modo che i dettagli emergano durante il lavoro.
  • Chiedere aiuto all’esterno ma evitare che diventi indispensabile.
  • Attivare una comunicazione efficace, fatta di storie e non di tecnicismi. Ascoltare attivamente, cercando di non giudicare le persone ma le conseguenze delle azioni.
  • Supportare i membri più trainanti.
  • Comprendere il cambiamento, i confini del “territory of change”, le implicazioni, gli attori coinvolti.
  • Non sottovalutare gli oppositori, provare a comprenderne le motivazioni senza per forza convincerli della bontà del cambiamento in atto.
  • Definire un piano e un ritmo basato su orari e impegno sostenibili per tutti.
  • Principi e valori del Radical Management sono universalmente validi, ma il modo con cui si implementano cambia di volta in volta. Per questo è importante provare, sperimentare, valutare quanto fatto e adattare: non esiste una ricetta precotta valida per tutti.

 

Conclusione

Con questo secondo articolo, terminiamo la discussione dedicata Radical Management, ossia a come introdurre all’interno della propria organizzazione un modo differente di fare management, ispirato comunque agli stessi concetti base dell’Agilità.

Dalla prossima puntata, inizieremo a vedere insieme i concetti che introducono al project management agile.

 

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] David Marquet, Turn the Ship Around!: A True Story of Turning Followers into Leaders. Portfolio, 2013

 

Condividi

Pubblicato nel numero
219 luglio 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