I principi e la loro applicazione

In questo e nel successivo articolo vorrei proporre una serie di considerazioni che riguardano il tema dell’applicazione di metodologie agili all’interno di aziende già ben strutturate e che spesso operano secondo uno stile “tradizionale” della gestione aziendale. Come è possibile farlo? Che tipo di approccio possiamo seguire? Quali sono le principali problematiche e i possibili sviluppi?

Le pratiche agili puntano a rilasciare valore all’utente finale tramite un processo iterativo e incrementale e grazie a feedback frequenti.

Tendenzialmente, tutte le attività che non contribuiscono a questo scopo fondamentale sarebbero da eliminare, cosa piuttosto facile da attuare quando si tratta della creazione di un prodotto.

Ben altro discorso si deve applicare un processo di trasformazione aziendale dove è necessario applicare un approccio completamente differente: si tratta quasi sempre di perseguire un percorso di cambiamento che sappia stare in equilibrio fra cultura aziendale esistente (che non deve e non può essere annullata), i processi in funzione (che non possono essere stravolti dall’oggi al domani) e l’introduzione di nuove pratiche e strumenti ispirati ai principi e ai valori dell’agilità con lo scopo di portare un concreto miglioramento nell’organizzazione.

Pianificazione e valore

Fra i molti ambiti dove mi sono trovato a lavorare per portare il pensiero agile, quello della pianificazione è certamente uno dei più interessanti, per esempio quello della gestione del piano annuale di lavoro.

Negli anni passati abbiamo assistito a una interpretazione dei principi agili che propugnava un approccio “oltranzista”: non si fanno i piani di produzione, non si può stabilire a priori chi lavora a cosa, non si compilano report dello stato di lavoro delle persone, non si fanno stime del costo di una epica o dello sprint. Tutto questo perché imbriglia il team che invece deve avere la massima libertà di auto-organizzarsi.

Un team agile, specie se alle prime armi, rischia di cadere nella convinzione che “noi lavoriamo in Agile e non possiamo darvi queste risposte, perché quel che ci state chiedendo di fare è micromanagement. Noi vogliamo fare solo quello che serve, che produce valore”.

Questo approccio “talebano” rischia di trasformare Agile da un concreto strumento per portare il miglioramento nell’organizzazione in qualcosa di astratto e disconnesso dalla realtà, vanificando anche gli sforzi fatti per implementare pratiche e strumenti.

Come è facile comprendere, questa risposta non è quasi mai considerata accettabile: la risposta corretta è mettere in evidenza il costo della pianificazione in rapporto al valore prodotto. Per costo in questo caso si intendono i costi evidenti, quelli direttamente connessi alla realizzazione del piano (qualcuno che lavora per produrre il piano), quelli indiretti (per esempio il fatto che il team debba fermarsi per produrre le informazioni per fare il piano potrebbe essere un costo non direttamente connesso col progetto) e quelli nascosti (dover rispettare il piano potrebbe poi impedire quel grado di cambiamento che una metodologia agile come Scrum non solo permette ma anzi favorisce). Tutto questo va confrontato col valore prodotto ovvero con l’affidabilità del piano stesso. Quante volte abbiamo rifatto il piano? Quanto ci costa tenerlo aggiornato? E che tipo di decisioni possiamo prendere visto che il piano cambia spesso. Tradotto, in parole semplici: “Ma serve davvero?”.

Per questo motivo vorrei raccontare la mia esperienza maturata in un caso reale, dove l’implementazione di processi e strumenti tipici dell’Agile si è dovuto confrontare con il resto dell’organizzazione che lavora in modo tradizionale.

Un contesto complesso

Nell’ultimo anno ho seguito un’azienda che si occupa di telecomunicazioni per settori strategici e che crea prodotti dove è richiesto un livello elevatissimo di qualità.

La produzione di tali prodotti, che prevedono hardware, firmware e software, richiede una pianificazione piuttosto stringente per rispettare i vari vincoli di progetto. Per esempio, per permettere i collaudi che possono essere svolti solo presso certi impianti specializzati, alcuni dei quali esterni all’azienda e in alcuni casi situati all’estero. Oppure per prevedere in anticipo i carichi di lavoro di personale specialistico (SME, Subject-Matter Expert) che non è disponibile in numero abbondante o di risorse fisiche che richiedono “prenotazioni” specifiche. Oltre che per coordinare il lavoro di progetto con le persone e le risorse,  la pianificazione serve inoltre per gestire la contabilità di progetto ovvero per avere un’idea abbastanza chiara dell’impatto sul budget, sui flussi di cassa e sui costi generali.

Sembrerebbe quindi un contesto poco adatto all’adozione pratiche agili. Vediamo come invece stiamo lavorando per far coesistere l’approccio predittivo con quello adattivo.

Come sono organizzati i team e come lavorano

Uno dei progetti che ho seguito in questo anno è relativo a un prodotto sviluppato da cinque team che si coordinano per la creazioni delle diverse parti:

• Team A che lavora in Scrum per lo sviluppo di software con dipendenze da firmware e hardware.
• Team B dove lavorano i progettisti dello hardware che utilizzano una metodologia derivata dal concurrent engineering (“ingegneria simultanea”), una metodologia di derivazione Lean utilizzata in vari settori industriali (automotive, aerospaziale, elettronica etc.) [1].
• Il Team C è invece focalizzato nella risoluzione dei problemi hardware–software-firmware, e lavora con una metodologia in cui ci sono una base di Scrum e svariati elementi di Kanban. L’abbiamo chiamato “Scrum + cap”, dove cap indica il limite temporale massimo che si dà ad alcune attività (corrisponde più o meno al termine spike che spesso si usa in Scrum).
• Team D: gruppo dedito alla realizzazione della documentazione, vincolata a rigidi protocolli di sicurezza. Lavorano in una logica di iterazioni stile Scrum, più un pull alla maniera Kanban sulle merge prodotte a fine sprint.
• Team E: gruppo di verifica; a motivo dei rigidissimi protocolli di sicurezza, tutte le parti, compresa documentazione e manualistica, devono essere passate al vaglio di un team di verifica per la validazione funzionale e non funzionale di ogni parte, anche la più piccola.

Come lavorano

Non entreremo troppo nei dettagli del modo in cui questi gruppi lavorano e collaborano. Diciamo solo che i cinque team, pur adottando approcci differenti — dallo Scrum puro a sistemi ibridi fatti di processi pull à la Kanban che si innestano su fasi iterative à la Scrum — hanno implementato una sorta di sistema di scaling simile per molti aspetti al framework Nexus [2] inventato da Ken Schwaber e dal gruppo di Scrum.org.

In realtà alcune cose sono state volutamente cambiate proprio per agevolare la transizione del lavoro da un modalità per silos a una di coordinamento fra i vari team.

I cinque team sono guidati ognuno da un proprio Product Owner e tutti sono coordinati da un Chief PO che passa ai PO l’elenco dei requisiti funzionali — il cosa si deve realizzare, mai il come — prelevandoli da un singolo backlog comune. Le assegnazioni sono sempre chiare, date le differenti mansioni del team. Questa è forse la scelta più distante da Nexus, ma è stata fatta per precise necessità di progetto e organizzative.

Questi cinque team hanno fin dal primo momento provato a lavorare seguendo i principi del Manifesto Agile e implementandone la filosofia, pur senza rispettare in toto le infrastrutture metodologiche che si trovano in letteratura (p.e. Scrum o Nexus).

Con le mille difficoltà che si possono incontrare quando si prova a cambiare radicalmente modo di lavorare, si è provato a seguire fin dal primo momento un approccio di sperimentazione e adattamento (inspect & adapt): adattando le tecniche, gli strumenti e i processi abbiamo cercato di applicare principi e pratiche Agile, pur tentando di rispondere alle necessità del resto dell’organizzazione tradizionale.

Temi e problematiche emerse

Rispetto ai cinque team, questo progetto però si muove in un contesto più ampio, fatto di commesse internazionali, pianificazioni di gruppo (una multinazionale), linee di produzione esterne ai team e molti altri aspetti che introducono vincoli e dipendenze.

Quindi i cinque PO più il Chief PO si sono trovati a lavorare con un approccio “agile” dovendo al contempo rispondere a richieste puntuali fatte di pianificazioni temporali ed economiche.

Di seguito, riportiamo un riassunto delle richieste provenienti dal resto dell’azienda.

Piano dei costi di progetto in relazione al personale coinvolto

A ogni PO è richiesto di prevedere i costi delle proprie attività, valutando

• il costo per lo sviluppo delle epiche del backlog sia considerando il team interno che il personale appartenente ad altre aree dell’azienda.
• il costo delle risorse fisiche coinvolte, per determinare i costi, ad esempio, di un pannello radiotrasmettitore da comprare/affittare o quello delle trasferte per i collaudi sul campo.

Piano delle allocazioni delle persone e delle risorse

Il gruppo di lavoro — composto dai cinque team, i PO di ciascun tam e il Chief PO — deve tener conto dei vincoli sulle persone e sulle risorse fisiche per poter fare il piano di lavoro di dettaglio, ossia la pianificazione di sprint in sprint con il backlog trisettimanale.

Per quanto nella teoria Agile si raccomandi la formazione di team stabili, questo non sempre è possibile in determinate situazioni. Per quanto riguarda le persone, pur lavorando con team base più o meno stabili, tutti i gruppi di lavoro si avvalgono frequentemente di figure esterne che collaborano in modo temporaneo e che afferiscono a linee di produzione esterne. Il capo di linea ha necessità di sapere  chi sarà coinvolto nel lavoro dei team, quando e per quanto tempo. Sebbene un team agile cerchi di rimandare il più possibile questo tipo di decisioni, chi farà cosa e quando, di fatto la mancanza di tale “prenotazioni” può portare alla non disponibilità di persone con competenze specifiche, indispensabili in un dato momento.

Discorso analogo vale per le risorse fisiche rappresentate tipicamente da componenti hardware, sistemi firmware o pezzi unici non replicabili ma necessari sia per lo sviluppo della parte hardware che per il test delle parti firmware e software: spesso questi elementi sono  a disposizione del gruppo in quantità limitata perché sono estremamente costosi o richiedono lunghi periodi di produzione per farne dei cloni.  I responsabili di tale materiale hanno necessità di sapere in anticipo quando, dove e per quanto tempo i dispositivi o i sistemi verranno spostati, pena l’impossibilità di reperire componenti indispensabili allo sviluppo.

In entrambi i casi — persone e risorse — si rende necessaria una calendarizzazione delle attività da svolgere, e quindi delle risorse necessarie,  che può apparire in un certo senso contraria alle abitudini del team agile.

Il tema che si è presentato subito è “Chi lo fa?”. Il PO? I developers? I direttori di linea? E per i costi (paragrafo successivo), chi è responsabile?

Piano dei costi di progetto relativamente alle risorse utilizzate

Strettamente collegato al punto precedente, i reparti finanziari dediti al controllo dei costi aziendali richiedono una pianificazione dei costi di progetto per evidenziare eventuali sofferenze, per esempio extrabudget da coprire, o permettere eventuali spostamenti fra gli stream di lavoro. Anche qui… a chi tocca fornire queste stime? Al PO? In questo caso i costi non sono direttamente sotto il controllo del team/PO ma sono in mano al responsabile finanziario della divisione e del progetto, quindi eventualmente il Chief PO.

Non chiedermi quello che non serve

Gli esempi appena descritti sono stati riportati con lo scopo di condividere reali casistiche prese dal mondo del lavoro. Lo scenario presentato mostra come le questioni siano spesso più ingarbugliate di quanto a volte si evince dalla letteratura più teorica.

Se cerchiamo di mettere al primo posto il valore effettivamente rilasciato, allora molte delle argomentazioni appaiono solamente come delle battaglie ideologiche che contrappongono il modello di management tradizionale con le tendenze degli agilisti più radicali.

Ma uno degli obiettivi primari della cultura Agile, che prosegue fortemente la cultura Lean di matrice Toyota, è concentrarsi solo su quelle attività che portano valore per qualcuno. Quindi, quando si porta Agile dentro una azienda, lo scopo dovrebbe essere prima di tutto quello di supportare gli stakeholders per capire se le cose da fare siano realmente utili e portino valore.

Se l’ufficio XYZ ci chiede un piano dei costi, perché è abituato a riceverlo e senza non potrebbe procedere nel proprio lavoro, o la previsione delle allocazioni delle persone/risorse, perché gli è necessario per poter pianificare il resto del proprio lavoro, probabilmente la cosa più semplice da fare è produrre tali piani e consegnarli a chi ce li chiede. Poi magari provare a stimolare un percorso critico per capire il reale bisogno: serve il piano o serve non bloccare un progetto perché le persone non sono disponibili il prossimo trimestre? La soluzione rapida, tattica è fare il piano, quella strategica con vista sul lungo periodo potrebbe essere creare un nuovo modello organizzativo magari allargando le competenze per supportare la nascita di team stabili.

Se qualcuno è abituato a considerare i documenti di piano necessari allo svolgimento del proprio lavoro, dobbiamo partire da questo punto anche se il team di sviluppo Scrum potrebbe tranquillamente lavorare senza di essi.

Poi, mantenendo una buona dose di realismo, bisogna anche dire che molto spesso la necessità di certi documenti richiesti da certi uffici non è basata su ragioni sensate, ma è frutto solamente di abitudini o credenze: “Si è sempre fatto così”, “Senza quei documenti non ci sentiamo rassicurati”; “Ma se non li abbiamo, vuol dire che perdiamo il controllo”, e così via. In situazioni come queste, in cui i documenti richiesti non apportano alcun valore effettivo, certe obiezioni dei puristi dell’Agile appaiono allora ben fondate.

Conclusioni

Quindi, come si procede? Lo vedremo in dettaglio nel prossimo articolo. Qui abbiamo voluto mettere in luce come, quando ci si interfacci con un contesto aziendale molto complesso e strutturato, certe eccessive semplificazioni non siano la soluzione, per quanto possano nascere da valori e principi sempre validi come quelli del Manifesto Agile.

Dal momento che lo scopo è quello di creare valore per l’utente, non dobbiamo mai perdere di vista se le azioni che ci vengono richieste possano effettivamente farlo. Se, neanche tanto per assurdo, alcune attività di pianificazione e documentazione possono effettivamente apportare valore al processo, allora forse dovremo riconsiderare il nostro scetticismo agile nei confronti di tali azioni.

Riferimenti

[1] Luigi Mandarino, Concurrent Engineering. Affinità–divergenze tra l’ingegneria simultanea e le metodologie Agile. MokaByte 307, luglio–agosto 2024
https://www.mokabyte.it/2024/08/05/concurrentengineering/

[2] The Nexus™ Guide
https://www.scrum.org/resources/nexus-guide