Introduzione

Questa serie di articoli è dedicata al tema dell’Agile che entra nelle grandi e grandissime aziende dove le migliaia di dipendenti sono organizzati in sottostrutture di vario tipo — tipo dipartimenti, divisioni o business lines — ognuna con una specifica funzione, in cui si fanno partire contemporaneamente decine di progetti, in capo ad altrettanti team.

In questi contesti, il focus della trasformazione agile non è più solo sul come attivare uno o più team Scrum e quindi sui compiti di uno o più Product Owner e di uno o più Scrum Master. Qui si tratta di capire quali sono i benefici che le metodologie agili possono fornire nel coordinare e guidare una mole di lavoro tanto grande: moltissimi stream di lavorazione portati avanti tramite le metodologie agili.

Scalare

Quando si inizia a portare l’agilità in un contesto più ampio, poco dopo si finisce per parlare di modelli di scaling, ossia di schemi organizzativi che consentano il coordinamento di vari stream di lavorazione o lo sviluppo di prodotti suddividendo la lavorazione fra diversi team. È un tema interessante: molti gli strumenti inventati in questi anni, diversi dei quali piuttosto riusciti. Quasi tutti hanno qualcosa che può concretamente aiutare per svolgere questo lavoro.

Nella mia esperienza — insieme a quella dei miei colleghi — ho però potuto osservare che la partita non si svolge intorno alla scelta di un particolare modello di scaling. La parte difficile è capire come supportare il cambiamento di mentalità, la trasformazione verso qualcosa di differente.

In questo processo, il ruolo del manager è essenziale, perché normalmente i team di sviluppo fin da subito accolgono questo nuovo modo di lavorare con entusiasmo e dedizione, ma la cosa non è automatica man mano che si sale nei livelli della classica organizzazione gerarchica.

Per capire come debba cambiare il modo di lavorare e di intendere l’organizzazione da parte del manager che voglia supportare l’applicazione di Agile in azienda, possiamo ripartire da una serie di articoli pubblicata qualche tempo fa su questa rivista [1]. Prendendo spunto da un interessante libro [2], parlammo allora di Radical Management, inteso come nuovo modo di fare management in una organizzazione in trasformazione.

Agile manager e radical management

Il radical management può essere visto come un modo di intendere il lavoro del manager all’interno di una di organizzazione di nuova concezione e basata sui seguenti punti:

• l’obiettivo del lavoro è la soddisfazione del cliente;
• fondare il lavoro su team autorganizzati;
• organizzare il lavoro secondo un approccio iterativo e incrementale;
• ogni iterazione deve rilasciare valore al cliente;
• incentivare la trasparenza;
• incentivare il miglioramento continuo;
• usare la comunicazione interattiva.

In questa sede vorrei concentrare l’attenzione sui punti evidenziati in grassetto, dal punto di vista del manager di una azienda: cercare di capire come una figura di questo tipo, supportando l’applicazione della filosofia agile nell’organizzazione, possa favorire l’autoorganizzazione, la trasparenza e il miglioramento continuo.

Autoorganizzazione

Molte sono le azioni che un manager può fare per stimolare la voglia delle persone di prendersi in carico la gestione del proprio lavoro quotidiano: probabilmente una delle più importanti è comunicare, costantemente e appassionatamente, gli obiettivi del lavoro, obiettivi che devono essere avvincenti e di valore, evidenziando in modo chiaro il beneficio per l’utente finale del proprio lavoro.

Per poter comunicare il valore, il manager, bilanciando delega ed emancipazione, deve quindi smettere di controllare le persone, i team, il processo, le modalità operative e passare a concentrarsi sul beneficio del prodotto, il cost of delay, la soddisfazione utente.

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

Un manager, un team leader, un responsabile di un gruppo dovrebbe lasciare al team la decisione su cosa fare all’interno di un ciclo di lavoro.

Oltre alla gestione di aspetti come la visione e la strategia, dovrebbe anche farsi carico di risolvere problemi più concreti che richiedano la sua autorità; per esempio trovare spazi di lavoro che consentano l’operatività o di appendere board operative, information radiator visuali e altri strumenti informativi, condivisi e di facile comprensione.

Trasparenza del team nei confronti del management

Il manager deve intervenire sulle questioni che solo lui può risolvere, recependo tutti gli impedimenti che possono interferire con il lavoro dei team di sviluppo. Per questo deve fare in modo che le persone si sentano libere di far emergere i problemi e che gli errori non siano percepiti come frutto di comportamenti da punire o rimarcare.

Trasparenza del management nei confronti del team e trasparenza del contesto.

Un responsabile, un Product Owner, un team leader dovrebbe sempre comunicare e condividere le priorità di progetto in modo chiaro e continuativo.

Quindi il comportamento migliore 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. Infine, il team dovrebbe sempre essere a stretto contatto con cliente e l’utente. Il management non dovrebbe dividerli.

Persone e interazioni più che processi e strumenti

Autoorganizzazione, comunicazione, condivisione, trasparenza sono concetti ormai assodati e condivisi dalla stragrande maggioranza delle persone che lavorano con Agile. Ma come si attivano queste dinamiche a livello del management e del top management?

Il portfolio progetti, gestito con un approccio agile, è certamente un ottimo elemento per raccogliere le idee, per filtrare quelle che sono candidate a diventare progetti e poi prodotti. È utile per abilitare dinamiche di conversazione, evidenziare punti di miglioramento, visualizzare e condividere la strategia di alto livello.

Abbiamo fatto molti esperimenti in tal senso e quello che vorremmo raccontarvi qui sono un po’ di considerazioni frutto del nostro lavoro sul campo.

Dal cono delle idee, al funnel, al portfolio

Da un punto di vista schematico, il portfolio permette la gestione di un processo come quello raffigurato in figura 1

Spesso rappresentato su una board fisica, mappa l’elenco delle attività in lavorazione in un determinato momento e lo stato di lavorazione.

Tipicamente, la board è suddivisa in due aree: quella della raccolta delle idee o delle nuove proposte — sulle quali si attua un processo di selezione e filtro nell’avanzamento verso destra — e la fase di esecuzione in cui le idee selezionate diventano delle vere e proprie iniziative o progetti di sviluppo.

Commitment Point

La linea di demarcazione fra le due fasi viene detta Commitment Point che rappresenta il passaggio dalla fase in cui le attività sono delle opzioni a quella in cui il team si impegna realmente a svolgerle (committed work).

Le attività che sono in fase di valutazione, sono delle opzioni che potrebbero non passare la selezione. David Anderson, autore del noto libro su Kanban [3], descrive questa parte utilizzando la metafora del concorso di bellezza, dove le storie fanno a gara per essere scelte: solo quando un item supera il commitment point prende importanza; prima di allora, è semplicemente una opzione.

Una volta messa in lavorazione, un’attività non dovrebbe mai essere abbandonata se non in casi eccezionali: per questo motivo si sceglie la parola commitment, che indica il “prendersi seriamente un impegno”. Dal punto di vista del cliente, la presa in carico di un’attività che passa il commitment point rappresenta una promessa, più o meno esplicita, che tale attività verrà portata a completamento, prima o poi.

Up Stream e Down Stream

Il processo di selezione (prima) e di implementazione (poi) può essere considerato come un unico flusso di lavorazione (“work flowing like a stream”) che scorre da sinistra verso destra; per questo la zona a sinistra del commitment point viene chiamata Up Stream (il corso iniziale del flusso), mentre quella alla destra è detta Down Stream (la porzione finale del flusso).

Per effettuare delle metriche di performance dell’organizzazione, spesso si prende in esame il lead time, vale a dire il tempo necessario per completare una attività. Il lead time non dovrebbe tener conto del tempo in cui le attività sono in Up Stream: in questa fase, il tempo di attesa non dipende dal processo.

Per valutare e selezionare le attività presenti in Up Stream, si può ricorrere alle tecniche tipiche utilizzate in Product Management o Risk Management. Ho parlato di queste tematiche in una serie precedente dal titolo Product Ownership e strategie di prodotto pubblicata a partire dal numero 233 di MokaByte [4].

Le tre viste

Se la figura 1 spiega a grandi linee cosa sia e come funzioni un modello di portfolio, non chiarisce come questo si traduca nel lavoro quotidiano del manager e come possa aiutarlo nell’implementazione di quei principi di trasparenza, comunicazione o più genericamente di “agilizzazione” della organizzazione.

In aiuto può venire l’introduzione di un’ulteriore dimensione con la quale “guardare” il portfolio: tre vere e proprie prospettive di osservazione — ma potrebbero essere di più o differenti — con le quali “osservare” la pipeline di iniziative: prospettiva operativa, prospettiva di coordinamento e prospettiva strategica.

La prospettiva operativa

Si tratta di una versione molto simile alla Kanban board di un team di sviluppo e offre una vista a un livello leggermente più alto (rispetto a quella del team), dato che aggrega differenti stream e ne offre una visione d’insieme.

Tipicamente si compone di una board dove le colonne rappresentano periodi temporali relativamente brevi: per esempio, se i team fanno Scrum, potrebbero essere 2-3 sprint o più semplicemente un mese. Le righe invece rappresentano i singoli team di lavoro.

I cartellini attaccati nelle varie celle sono le generiche “iniziative” che quel team svolge in quel mese. Non sono storie (troppo piccole), probabilmente non sono epiche (troppo grandi?); potrebbero essere “macroiniziative” (p.e., l’obiettivo dello sprint o una “minimilestone”).

Un modo adeguato per capire quale possa essere la grana giusta delle iniziative potrebbe essere di iniziare decidendo di non inserire più di 2-3 elementi per unità temporale. Poi, con il tempo, in base all’osservazione del sistema, si può aggiustare questa variabile: vedremo più avanti come.

La prospettiva di coordinamento

La prospettiva operativa spesso serve ai Product Owner — e ai relativi coordinatori nel caso di sistemi di scaling tipo Scrum of Scrums — per capire cosa sta succedendo dentro i vari team e facilitare il coordinamento fra i progetti

In questa accezione, il portfolio diventa un portfolio di coordinamento in cui si mettono in evidenza propedeuticità tecniche o funzionali fra gli elementi dei vari backlog, allineamenti temporali fra stream di produzione differenti. Spesso la grana è leggermente più grossa, essendo necessari meno dettagli funzionali.

Da un punto di vista prettamente operativo, la board viene gestita direttamente dai Product Owner che si incontrano con una cadenza compatibile con quella del ritmo di lavorazione; per esempio, nel caso che tutti i team facciano Scrum con sprint da 2 settimane, la cadenza potrebbe essere una volta al mese, ma poi sono gli stessi partecipanti che possono decidere se sia necessario intensificare gli incontri o diminuirli.

Il portfolio strategico

Aumentando prospettiva della visione si può introdurre il portfolio strategico (vista ad alto livello) in cui si riportano macroattività relative a intervalli temporali molto ampi (p.e. trimestri) e in cui le righe non raccolgono tutti gli stream dei singoli team, ma aggregano il lavoro per unità di business, factory di produzione o altri elementi aggregativi (p.e. le tribù del sempre citato Spotify Model).

In questo caso la vista permette, di solito al top management, di osservare a livello macroscopico dove sono stati investiti soldi e risorse e se queste iniziative sono in qualche modo in linea con gli obiettivi aziendali

Agile portfolio management per la trasparenza e l’autoorganizzazione

Ora che abbiamo visto a grandi linee cosa sia un agile portfolio, resta da capire come questo non sia un semplice e solo strumento, ma anzi sia un qualcosa che abiliti i due principi di cui abbiamo parlato nella prima parte di questo articolo e che dovrebbero essere elementi fondamentali per il manager che voglia diventare un agile manager: trasparenza e autoorganizzazione.

Vediamo il primo aspetto: in che modo il portfolio può abilitare la trasparenza da e verso i team, da e verso l’organizzazione? Ovviamente tutto dipende da come questo strumento — che è, e resta, uno strumento — viene creato, alimentato, utilizzato, gestito.

In tal senso, proprio in ottemperanza di uno dei valori del manifesto, il portfolio non deve essere semplicemente uno strumento: deve abilitare la comunicazione e l’interazione. Se questo viene fatto in modo opportuno, diventa anche incentivo alla trasparenza.

Per questo promuoviamo l’uso di lavagne fisiche, non strumenti elettronici, disposte in luoghi congrui che permettano alle persone di colloquiare e scambiare informazioni in modo aperto e interattivo.

I Product Owner, per esempio, devono poter parlare liberamente davanti a colleghi di quello che sta facendo il proprio team, devono poter spostare un cartellino da una colonna a un’altra e comunicare a tutti cosa ciò significhi. Devono poter attaccare evidenti “tag” se ci sono impedimenti. Devono poter tracciare in modo visibile le dipendenze. Tutti devono poter assistere a questi incontri di allineamento. L’aggiornamento della board deve essere sotto la responsabilità e la proprietà dei diretti interessati, non delegato a un fantomatico ufficio PMO o Product Owner dei Product Owner.

La board dovrebbe essere disposta in un luogo dell’ufficio liberamente accessibile, meglio se di transito, proprio come la Kanban board di un team Scrum è appesa nella parete della stanza del team e tutti possono vederla. Non devono esserci segreti fra il management e gli operativi. Inoltre, le board dovrebbero essere scritte con terminologie e simboli che tutti possano comprendere.

Tutto questo vale certamente per le prime due prospettive dell’Agile Portfolio: organizzativa e di coordinamento. Un qualsiasi developer, uno Scrum Master, uno stakeholder devono tutti poter vedere se il proprio progetto è in ritardo o se è stato fermato per dipendenze da altri progetti che sono bloccati. Tutti devono poter capire come organizzare il proprio lavoro se devono esserci delle sincronizzazioni, specialmente fra team Scrum e team che usano metodologie di produzione tradizionali. Tutti devono poter intervenire in ogni momento

Quanto appena detto, però, deve valere anche per la prospettiva di più di alto livello, quella strategica: compatibilmente con la riservatezza ed eventuali segreti industriali, ogni persona coinvolta dovrebbe poter vedere se un progetto è stato fermato o se è meno importante di un altro, e se ci sono strategie aziendali che possano impattare sulle scelte progettuali.

Ma davvero?

Quanto abbiamo appena detto sarà percepito come irrealizzabile, incompatibile con il modello organizzativo, con la gerarchia di comando, con le regole di gestione. Siamo consapevoli che questo approccio mina una certa visione dell’azienda, mette in discussione la cultura tradizionale e si presenta come un ariete che vuole far crollare alcuni pilastri fondamentali. Da molti, questo approccio verrà visto come uno sforzo inutilmente pericoloso o dannoso.

Comprendiamo benissimo la difficoltà di implementazione in una organizzazione tradizionale di quanto appena esposto in questo articolo. Ma sappiamo anche che non tutto deve e può essere realizzato il primo giorno: molto può essere raggiunto grazie a un percorso incrementale, fatto di piccoli ma significativi passi. Una volta intrapresa pian piano questa via, il cammino possibile verso la trasparenza e l’autoorganizzazione — e verso una più globale trasformazione in senso agile dell’organizzazione — apparirà inarrestabile. Inopinabile.

E poi?

Dopo questo aspetto, resta da vedere come la pratica dell’Agile Portfolio Management possa stimolare l’autoorganizzazione delle persone e più largamente, visto il tema Agile for Managers, delle unità (team, aree operative, fabbriche del software etc.).

Il prossimo mese, quindi, vedremo esattamente questo, ossia come una sapiente organizzazione e classificazione dei progetti, delle competenze e degli staff possa essere fatta direttamente dalla persone. Il manager deve mutare la sua prospettiva e passare dalla gestione delle persone a preoccuparsi di come rilasciare prodotti di valore.