Cosa significa “qualità” quando il team non sta producendo software

Abbiamo parlato recentemente dell’importanza dell’eccellenza tecnica nel software. Ma come è possibile valutare l’impatto dei principi e delle pratiche agili nei progetti “non software”?

Dal software al prodotto in genere

Come direbbero gli americani: “the cat is out of the bag”. Non è più un mistero che una buona percentuale dei gruppi di lavoro che si avvicinano all’agilità sono team che non fanno software e che spesso lavorano in aziende in cui il software non è neanche il core business, ma “solamente” — si fa per dire — un fattore abilitante.

È un argomento di cui, specie da noi, ancora si parla poco e, soprattutto, in maniera molto generalizzata, pur essendo una delle situazioni che incontriamo sempre più spesso: l’azienda decide di adottare Agile, e i primi team che si incontrano non hanno al loro interno né programmatori, né designer. Che fare?

In questi casi lo sconforto dell’Agile Coach può essere grande, così come lo sconforto del team, che si rende rapidamente conto di tutti i limiti organizzativi che dovrà affrontare per riuscire a fare anche solo una piccola percentuale del progetto.

Figura 1 – Non tutti i prodotti da realizzare sono necessariamente software.
Figura 1 – Non tutti i prodotti da realizzare sono necessariamente software.

 

L’entusiasmo per il “lavorare in Agile” lascia molto rapidamente il campo alla frustrazione: la strada verso l’idea che “Agile non funziona” è di fatto spianata…

 

Dall’eccellenza tecnica alla qualità in altri contesti

Quando parliamo di qualità in Agile parliamo principalmente di qualità del software, di eccellenza tecnica, come dicevamo nel nostro articolo Agile Tech: per non scordarsi dell’eccellenza tecnica. Ma in questo periodo viviamo in una situazione di stallo riguardo alle aspettative sull’agilità: da un lato, principi e pratiche Agile si sono espanse in ambiti sempre più vari, tanto che ormai “Agile” associato sempre più spesso a temi organizzativi a non a temi tecnologici; allo stesso tempo, non abbiamo una definizione solida e condivisa di cosa significhi “qualità” quando non sono gli aspetti tecnologici a farla da padrone.

Nel corso del tempo, da parte nostra, abbiamo individuato una serie di dimensioni che ci permettono di identificare in che modo un team che non fa software può produrre lavoro di qualità:

  • comprensione del contesto
  • decisioni
  • obiettivi
  • ritmo

La premessa — importante e se vogliamo anche audace — ai ragionamenti che seguono è questa: se il software funzionante non è più la principale misura di progresso del vostro team e se l’eccellenza tecnica non può essere un fattore fondamentale, automaticamente è la qualità del lavoro stesso a dover essere presa in considerazione.

 

Comprensione del contesto

Al fine di produrre lavoro di qualità, un team può anche non fare software, ma non può essere inconsapevole del proprio posto nel mondo. In particolare ecco di cosa è importante essere consapevoli:

  • posizionamento e scopo
  • complessità organizzativa
  • dispersione della conoscenza

 

Posizionamento e scopo

Non è infrequente il caso in cui un team che non fa software sia comunque ritenuto responsabile anche della parte esecutiva.

Figura 2 – La parte “esplorativa” e quella “esecutiva”.
Figura 2 – La parte “esplorativa” e quella “esecutiva”.

 

Un modello che spesso ci troviamo a utilizzare e spiegare ai team è il seguente: dividere la parte esplorativa da quella esecutiva è importante per focalizzare lo scopo del team, che rischia di pensare troppo a cosa non riesce a fare — per mancanza di visibilità diretta sull’implementazione dovuta alla distanza dai team di sviluppo — invece di concentrarsi sulle competenze di problem solving che il team può mettere in campo nella fase esplorativa.

Il grafico di figura 2 evidenzia inoltre un fatto importante: non è sufficiente che il team validi tutta una serie di ipotesi riguardo i clienti finali, ma deve verificare anche tutta una serie di ipotesi legate all’organizzazione interna.

Questo è spesso lontanissimo dal produrre software di qualità, ma è comunque lavoro che il team può fare in modalità collaborativa, co-progettando tutte le iniziative necessarie per portarsi più vicini al “punto di commitment”.

Un team che ha chiara la differenza tra discovery ed execution, e riesce a plasmare la propria responsabilità rispettando questo contesto, mettendosi nella condizione di evidenziare i “commitment point” in maniera precisa e puntuale, è un team che sta facendo lavoro di qualità.

 

Complessità organizzativa

Una delle cause più grandi di frustrazione è dover digerire il fatto che l’organizzazione del team di progetto sarà resa estremamente difficoltosa dal momento in cui l’iniziativa “taglierà” orizzontalmente diverse funzioni aziendali.

Figura 3 – Un “progetto agile” attraversa diverse funzioni aziendali.
Figura 3 – Un “progetto agile” attraversa diverse funzioni aziendali.

 

Mettere persone in una stanza è relativamente facile; fare in modo che queste persone abbiano chiara l’influenza di quello che succede fuori dalla stanza è un decisamente più complesso.

Un team che visualizza ed è maggiormente consapevole della complessità organizzativa in cui opera è un team che sta aumentando la qualità del proprio lavoro.

 

Dispersione della conoscenza

Quando si lavora in ottica di redesign di un processo è molto frequente che:

  • il numero di persone coinvolte sia molto alto;
  • la conoscenza del processo sia estremamente frammentata e dispersa.

Questo mette in crisi il modello del “pizza team” e il modello del team Scrum così come viene descritto in letteratura. Invece di un team di 5-7 persone abbiamo un team di 20 o più persone.

Occorre introdurre nuovi paradigmi per gestire gruppi di lavoro: il modello a cui ci ispiriamo è quello che prevede un gruppo di persone coinvolte — spesso chiamato “core team”— circoondato da una cerchia di persone interessate e da una cerchia di persone informate.

Figura 4 – La schematizzazione del modello “a cerchie” a cui ci ispiriamo.
Figura 4 – La schematizzazione del modello “a cerchie” a cui ci ispiriamo.

 

Questo modello ci permette di:

  • gestire gruppi molto più grandi di quelli previsti dalla “letteratura”;
  • individuare le caratteristiche specifiche di questi gruppi;
  • organizzare contenuti e cadenza degli incontri.

 

Decisioni

Un team che lavora in agilità prende decisioni, le prende frequentemente, e testa ipotesi in continuazione: questo è un aspetto per niente secondario e influisce direttamente sulla qualità delle decisioni che vengono prese dentro e fuori dal team.

Una decisione di qualità è la decisione più veloce e condivisa che possiamo prendere per produrre un incremento nei nostri obiettivi — per esempio, raccolta feedback, incremento di prodotto, ampliamento dell’impatto — senza rischiare di dover rimediare in modo costoso se si rivela “sbagliata”.

Volendo approfondire la questione, possiamo affrontare il tema “decisioni” guardandolo da diverse angolature:

  • “decisioni waterfall” vs. “decisioni agili”
  • condivisione dei criteri di prioritizzazione
  • velocità

 

“Decisioni waterfall” vs. “decisioni agili”

È una contrapposizione becera, il cui senso è che molto spesso Agile viene visto dal top management come il “piede di porco” per accelerare le decisioni e, direttamente o indirettamente, accelerare il time-to-market dei progetti.

Figura 5 – Colmare un gap molto ampio tra decisioni di visione a livello elevato e decisioni più immediate che il team deve prendere giorno per giorno.
Figura 5 – Colmare un gap molto ampio tra decisioni di visione a livello elevato e decisioni più immediate che il team deve prendere giorno per giorno.

 

Il contesto decisionale da cui si parte con un progetto Agile però è quello “non Agile”, in cui buona parte delle decisioni vengono prese fuori dal team.

Un team che lavora con qualità è un team in grado di colmare il gap tra le decisioni di “vision” del top management e le decisioni sul day-by-day dei singoli componenti del gruppo: è un gap spesso molto ampio di cui è meglio prendere coscienza il prima possibile.

 

Condivisione dei criteri di prioritizzazione

Un aspetto cruciale del poter prendere decisioni, e poter migliorare con il tempo la qualità delle decisioni, è quello di avere dei criteri di prioritizzazione condivisi.

Come dicevo nel paragrafo precedente, il gap tra la vision aziendale e il task management giornaliero fa sì che ci sia un abisso informativo tra i criteri di prioritizzazione che vengono usati nei diversi livelli della gerarchia aziendale.

Sempre più spesso ci troviamo a introdurre nei team tecniche di prioritizzazione che tengono conto di molteplici criteri, in modo da poter “pesare” le decisioni da più punti di vista, per creare roadmap e strategie.

Il lavoro di qualità di un team emerge in presenza di criteri di prioritizzazione che sono molteplici, dinamici, condivisi e utilizzati per pesare di volta in volta le decisioni da prendere. Un team che migliora la qualità del proprio lavoro è un team in grado di prioritizzare dinamicamente ciò che prima veniva prioritizzato arbitrariamente al di fuori del team.

 

Velocità

Ad alcuni la misura della velocità può bastare. Non vogliamo cadere però nella equivalenza velocità = qualità. È l’aspetto più evidente, ed è il feedback che più frequentemente riceviamo dopo un workshop: “In due giornate di lavoro abbiamo prodotto quello che normalmente ci richiede settimane”.

Il primo focus deve essere sulla qualità e quantità di idee che siamo riusciti a condividere e, solo secondariamente, sul fatto è stato possibile farlo in poco tempo: la velocità delle decisioni non è un obiettivo ma una caratteristica emergente.

Seguendo quanto detto nei precedenti due paragrafi sulla ownership delle decisioni e sulla prioritizzazione, potremmo dire che un team che produce lavoro di qualità è quello che può prendere decisioni veloci sul lavoro da fare ed è libero di affrontare le conseguenze positive o negative del lavoro validato.

 

Obiettivi

Un aspetto correlato, direi abilitante alla qualità delle decisioni, è quello degli obiettivi. Osserviamo molto di frequente che i team e le aziende non sono abituati a definire bene gli obiettivi.

Figura 6 – È importante definire bene gli obiettivi.
Figura 6 – È importante definire bene gli obiettivi.

 

Questo aspetto si collega al tema del gap comunicativo tra top management e gruppo di lavoro sul tema delle decisioni: così come un team deve avere la ownership delle proprie decisioni, un team dovrebbe avere anche la capacità di declinare i propri obiettivi e trasformarli in obiettivi di rilascio iterativi e incrementali.

 

Qualità del ritmo

La frammentazione organizzativa cui abbiamo fatto riferimento nei paragrafi precedenti ha effetti negativi sulla cadenza del lavoro in azienda.

Difficile bloccare le agende, difficile avere follow-up: tutti sono estremamente occupati sulle proprie attività personali, fino quasi a dissolvere completamente i concetti di progetto o prodotto.

Figura 7 – Cadenza e ritmo nel lavoro in azienda sono cruciali per la riuscita dei progetti.
Figura 7 – Cadenza e ritmo nel lavoro in azienda sono cruciali per la riuscita dei progetti.

 

Uno dei motivi per cui Scrum si è diffuso così tanto nelle aziende è che, da questo punto di vista, è un potentissimo “abilitatore di cadenza”: gli standup giornalieri, il refinement, la review e la retrospettiva aiutano il team a “ritrovarsi” anche quando le persone si trovano separate da diverse funzioni aziendali.

Un team che produce lavoro di qualità è un team che onora il 12° principio del Manifesto Agile:

A intervalli regolari il team riflette su come diventare più efficace, dopodiché regola e adatta il proprio comportamento di conseguenza

Anche se non fa software.

 

Oltre Agile?

Spesso ci troviamo a discutere su cosa sia o non sia Agile. A tratti è demoralizzante: significa che Agile è diventato troppe cose, e che regna la confusione. Agile è mera consulenza? È solo consulenza organizzativa e di processo? È solo consulenza tecnica? Che cos’è il coaching?

Giova ricordare che, in primo luogo, siamo nel campo del cambiare il modo in cui le persone lavorano e hanno lavorato per buona parte della loro carriera: non è un ambito a cui, a una domanda qualsiasi, si possa dare una risposta con soluzione arbitraria.

In questo articolo abbiamo descritto una situazione comune e l’abbiamo paragonata alla definizione, parziale e limitata, di cosa significhi qualità in Agile: il risultato è che occorre trovare, in maniera empirica, una definizione comune di qualità che si integri a quella della qualità del software.

“Qualità”, in un team che non fa sofware, è principalmente misurabile attraverso la qualità di tutto il lavoro fatto: ogni decisione, ogni riunione, ogni momento di co-progettazione, ogni slide, ogni foglio Excel possono essere fatti nel migliore dei modi.

Aiutiamo i team a scoprire nuovi modi per fare lavoro di qualità, accogliendo tutte le sfumature e i significati che questa parola può avere per diverse aziende e gruppi di lavoro.