Le cose cambiano…

Da quando esiste MokaByte, e sono più di venti anni, la mia attività professionale, e quella di tanti autori di questa rivista, almeno dei più anziani, è cambiata molte volte . Al di là del generico “Lui? Lavora con i computer…” — vecchia formula tanto priva di senso quanto utile in passato per catalogare tutti coloro che a qualsiasi titolo lavorassero nell’IT — il “mestiere” svolto da chi scrive si è mosso tra le varie incarnazioni in cui in tanti sono passati: programmatore — si diceva così, perché “sviluppatore” o “developer” sono parole arrivate dopo —, formatore, architetto IT, project manager, con le diverse declinazioni che in tanti abbiamo attraversato.

Ma oggi svolgo sostanzialmente la professione di agile coach e vorrei raccontare cosa fa un agile coach e ancor più quale sia il modello operativo di una azienda in cui questo “mestiere” viene svolto in maniera compiuta. Non ne parlerò in modo astratto e generico, ma racconterò in prima persona la mia esperienza.

Ma chi è un coach agile?

Un paio di anni fa ho avuto modo di trattare l’argomento parlando della differenza fra un formatore, un consulente, un coach e un agile coach. Quell’articolo [1], per quanto scritto di fretta e con spirito goliardico, è stato molto apprezzato al punto di essere pure utilizzato in un corso di scrittura creativa: in effetti era anche abbastanza divertente, qualità che di sicuro non viene al primo posto per un articolo su MokaByte, ma che di sicuro non guasta quando c’è.

Ma in questo articolo vorrei spingermi più in là, aggiungendo alla descrizione della figura dell’agile coach anche la definizione del modello operativo di una azienda che svolge questo tipo di attività. Ovviamente, quanto leggerete non è l’unico modo di intendere questo “mestiere”, né è detto che sia il migliore; è semplicemente quanto siamo arrivati a fare nell’azienda [2] con cui svolgo questa attività.

Cosa fa un coach agile…

…e come lo fa. Anzitutto va ricordato che nell’agile coaching si svolgono molte attività differenziate, e per queste sono necessarie al professionista molte competenze afferenti ad aree diversificate.

Il contesto in cui si opera

Prima di illustrare le attività e le iniziative con le quali applichiamo nel concreto la nostra professione di agile coach, c’è un aspetto che non va mai dimenticato, ed è quello della considerazione del contesto in cui si va a operare.

La premessa di ogni intervento è l’attenta osservazione della cultura aziendale presente nell’ambito in cui si opererà: magari ci saranno anche degli aspetti che non si condividono, o degli elementi che si considerano disfunzionali, ma senza il rispetto per questa cultura, non si parte con il piede giusto.L’insieme di valori e comportamenti che possiamo riscontrare in un dato contesto aziendale hanno alle spalle delle persone, delle motivazioni, delle storie: non adottiamo approcci dirompenti alla “è tutto sbagliato, è tutto da rifare”, ma cerchiamo di riconoscere questi elementi. A partire da questo riconoscimento, sarà poi possibile riorientare gradualmente la cultura aziendale in vista di un vero e proprio cambiamento.

Tre macroaree… e un’importante questione

Con questa consapevolezza, è possibile parlare del lavoro di agile coaching nelle aziende identificando tre macro aree: tecnica, processi, persone.

Area tecnica: pratiche e tecniche

È vero che sempre più diffusa è l’applicazione degli approcci agili anche a produzioni non software ma, di fatto, gran parte del lavoro si svolge con aziende o gruppi che sviluppano software. E in questo ambito, assumono grande importanza pratiche e tecniche: il pensiero agile si implementa nel concreto applicando l’eccellenza tecnica nel proprio lavoro, concetto che sintetizziamo usando la definizione di Agile Tech.

Questo significa ad esempio adottare i principi dell’Extreme Programming (XP) [3] e trasferire conoscenze tecniche tramite la formazione: per esempio, insegnare come si sviluppa codice partendo dai test, oppure che cosa vuole dire fare refactoring; successivamente, il gruppo deve essere comunque supportato tramite coaching tecnico durante l’esecuzione del progetto.

Processi: metodi e strumenti

Attraverso l’introduzione di opportuni metodi e strumenti, supportiamo le organizzazioni per far evolvere il loro processo di produzione in chiave agile. Si tratta di un’area dall’estensione molto ampia e che comprende contenuti anche molto differenziati: strumenti come Scrum o Kanban che possono aiutare a portare avanti il progetto; modelli di riorganizzazione dei team (da component team a feature team) [4]; tecniche di envisioning e così via.

Persone: soft skills e Agile HR

Non è possibile dimenticare che qualsiasi pratica, tecnica, metodo o strumento non funziona di per sé in modo astratto, ma si concretizza nell’adozione da parte di persone. Per questo la terza area da curare è quella che alle persone far riferimento e che, con termine forse imperfetto ma comunque efficace, viene chiamata Agile HR.

Qui assumono rilievo le cosiddette soft skills, vale a dire tutte quelle competenze trasversali che riguardano l’interazione fra le persone, la comunicazione, la collaborazione, le dinamiche di gruppo, l’identificazione del proprio ruolo in un’organizzazione che si sta trasformando. Questa è un’area molto importante perché ha un notevole impatto sulle prestazione del gruppo stesso, e facilita notevolmente l’adozione dei processi e delle pratiche agili, lavorando anche sull’evoluzione organizzativa, supportando la gestione del personale, la crescita umana e professionale, la strategia di retribuzione e riconoscimento delle performance.

L’importante questione: scalare Agile

Le tre macroaree appena descritte devono spesso confrontarsi con una fondamentale questione: scalare o allargare agile.

Quando parliamo di modelli organizzativi, specialmente con medie e grandi aziende, ci troviamo spesso ad affrontare il tema relativo all’allargamento dell’adozione di Agile: un conto è applicare l’agilità a uno o a qualche team, un altro ampliare all’intera organizzazione il modello agile. E anche la strategia con la quale seguire questo percorso è tutt’altro che scontata. Dal basso? Dall’alto? Big Bang o percorso graduale?

Il problema è condiviso e, da qualche anno, sono proposti sul mercato alcuni modelli operativi detti framework di Agile Scaling: SAFe, LeSS, Disciplined Agile, Spotify Model e altri ancora. Cambiare un’organizzazione non è affatto un compito semplice, e non è possibile applicare un approccio deterministico e pianificativo; tali modelli siono delle importanti fonti di ispirazione e di approfondimento a cui attingere per capirne pregi e difetti, ma è semplicistico e probabilmente poco sensato applicarli così come sono, in modo pedissequo.

L’approccio più adeguato è forse lavorare insieme al cliente in modo da comprendere insieme bisogni e obiettivi, e impostare un percorso di trasformazione — parola abusata che non è neanche troppo precisa — che sia anzitutto adatto a quella specifica situazione.

Se realmente onoriamo il nostro lavoro di coach agili, non dovremmo mai fornire la soluzione preconfezionata — “applica LeSS e vedrai che tutto funziona” — ma aiutare piuttosto il cliente a individuare la sua strada che funzioni e che gli permetta di cambiare e migliorare; il tutto, comunque, sempre in linea con i valori e principi dell’Agile Manifesto [5]. Spesso in questo contesto è bene muoversi affiancando il management con quello che chiamiamo Agile4Managers (attività di consulenza, formazione, coaching).

Rendersi dispensabili prima possibile

L’attività di agile coaching è, per sua natura, un insieme di operazioni volte a far emergere le soluzioni da parte di chi la richiede. Non è la proposizione di una soluzione già preconfezionata — magari anche valida e sensata — che però viene calata dall’alto nel contesto aziendale. Al contrario, il coach agile supporta il cliente ad arrivare alla “sua” soluzione.

Questo implica che nelle attività dell’agile coach si possano riscontrare diversi atteggiamenti che consentano la partenza dei team e dei progetti, ma al contempo garantiscano il proseguimento del lavoro anche quando i coach agile se ne vanno via.

Per tale ragione, tipicamente all’inizio percorso di affiancamento, ci sono momenti in cui i coach agili agiscono in qualità di formatori o consulenti: in questa fase si spiegano i concetti basilari e si forniscono le indicazioni necessarie per partire.

Siamo noi alla guida e le figure coinvolte iniziano ad apprendere, e quindi ad agire, seguendo i nostri consigli oppure semplicemente osservandoci in azione: per le prime volte sono i coach agili che facilitano una retrospettiva Scrum o che guidano lo Sprint Planning; con il tempo, prendono il controllo lo Scrum Master e il Product Owner prendono, e il coach agile recupera un ruolo di osservatore [1].

Il percorso di affiancamento da consulente a coach

In figura 1 è riportato uno schema che illustra il tipo e la “quantità” di coinvolgimento dell’agile coach: si parte con una situazione in cui siamo consulenti e attori attivi — spiegare, guidare, suggerire soluzioni — e si arriva a un punto in cui si fa coaching puro, stimolando il pensiero critico, interrogando le persone sul modo migliore secondo loro per fare una cosa, e così via.

Occorre sempre ricordare che, quando si indossa “il cappello del coach” [6], non si dovrebbe mai dare risposte o fornire soluzioni, ma invece aiutare il coachee a definire i suoi obiettivi e sostenerlo nel raggiungerli.

Un modello operativo per l’agile coaching

Moltissime sono le attività che un agile coach — o meglio un team di coach — può svolgere all’interno di una organizzazione che abbia deciso di adottare le metodologie agili. Si va dal setup di team per lo sviluppo di un prodotto, all’allargamento al resto dell’organizzazione — quello che spesso viene detto scaling —, al lavoro con le persone (carriere, crescita professionale, introduzione di competenze come i coach interni) e altro ancora.

Semplificando al massimo, proverò a elencare sinteticamente una serie di attività:

• Assessment
• Formazione
• Setup
• Project inception | “From Vision to Backlog”
• Coaching su progetto

Assessment

Una iniziale attività di valutazione è necessaria per capire esattamente quali sono le necessità del gruppo, quali gli obiettivi. In questa attività di assessment spesso si prova a concordare un piano d’azione comune: per esempio, se sia necessario fare delle attività di formazione e di che tipo; se il team debba sviluppare un prodotto e di che tipo oppure se dovrà erogare un servizio su richiesta dell’utente finale, e così via.

Formazione

Per quanto spesso sia necessaria una adeguata formazione sui concetti base e sugli strumenti necessari per lavorare, capita anche di entrare “in corsa” su team che già possiedono una buona conoscenza degli strumenti di lavoro. Per quanto riguarda la formazione, nella maggioranza dei casi si tratta di corsi su Scrum o Kanban, con una prevalenza del primo. Questa fase è “breve”, due o tre giorni, e si rimanda al training on the job, durante il progetto, la concretizzazione degli argomenti presentati.

Setup

Può capitare che il cliente chieda di aiutarlo nell’attività di setup del gruppo di lavoro. È bene ricordarlo: un coach non dovrebbe fornire soluzioni, né tantomeno suggerire un modo preconfezionato per plasmare il gruppo di lavoro. Per questa ragione cerchiamo sempre di stimolare la formulazione di ipotesi e idee, per esempio sul dimensionamento del team o sui razionali per scegliere il Product Owner o lo Scrum Master limitandoci solo a puntualizzare alcuni aspetti, ad esempio il fatto che il DevTeam non superi un certo numero di persone, oppure che Product Owner e Scrum Master non siano la stessa persona.

Project inception

Nota anche come “from vision to backlog”, l’attività di avvio del progetto è essenziale e serve per definire l’essenza del prodotto/servizio che dovrà essere sviluppato, ossia la vision. È qui che si individuano il target (a chi è rivolto il prodotto che dobbiamo realizzare), le necessità di business che risolve, la value proposition insita in esso. L’attività termina con l’identificazione degli elementi del backlog che poi potranno essere implementati dal gruppo di lavoro grazie a Scrum o Kanban.

Coaching su progetto

Nelle attività di vero e proprio coaching, si affianca il gruppo per completare la parte formativa o rinforzare alcuni concetti non ancora digeriti dal gruppo. Spesso, all’inizio il coach svolge lui in prima persona alcune attività come facilitare alcune riunioni — per esempio le “cerimonie” di Scrum —, strutturare il backlog o coordinare il Product Backlog Refinement. Durante le prime sessioni le persone del team osservano e piano piano iniziano a provare il lavoro visto fare al coach. Per esempio, le prime retrospettive del team sono facilitate dal coach e lo Scrum Master osserva. Dopo un po’ di tempo i ruoli dovrebbero essere invertiti: lo Scrum Master faciliterà e guiderà, mentre il coach starà zitto in un angolo fornendo poi solo alcune indicazioni migliorative.

Le fasi dell’attività di coaching con il team

La tabella seguente schematizza in varie fasi il percorso di crescita del team che si cerca di stimolare con il coaching agile.

Conclusione

Applicare Agile vuol dire applicare i valori e i principi dell’Agile Manifesto calandoli nel peculiare contesto in cui si opera: per questo, al di là di alcune invarianti, ogni azienda, ogni progetto, ogni esperienza è un caso a sé stante. Non è quindi pensabile definire una modalità operativa standard valida per tutte le casistiche. Un approccio sensato al coaching agile è fatto di sfumature, varianti, declinazioni. Quanto descritto in questo articolo, quindi, è solo la proposta di un possibile modello operativo, per quanto reale e applicato concretamente. Cercare un approccio differente, che diventi “il vostro approccio”, è sicuramente una buona e sana attività.