Feature Team VS Component Team e il ruolo del Product Developer: tutto quello che c’è da sapere

Scritto da

Marcello Rossi -

Feature Team VS Component Team. Quali sono le differenze tra i due e la (possibile) soluzione?

Per “feature team” (a volte chiamato “cross-functional team”) si intende quel modello organizzativo in cui il gruppo di lavoro raccoglie tutte le competenze necessarie alla realizzazione del prodotto. Quindi, ogni squadra sarà composta da sviluppatori backend, frontend, devops engineers, data scientist, eccetera.

Feature Team

Il modello organizzativo opposto è quello dei component team, in cui ogni gruppo raccoglie esclusivamente persone con competenze verticali che dovranno successivamente coordinarsi fra di loro. Abbiamo quindi diversi team composti rispettivamente da soli sviluppatori backend, soli frontend e via dicendo.

Component Team

Nelle realtà di prodotto e nei contesti fortemente orientati all’agilità è ormai prassi consolidata fare riferimento al concetto di “feature team”. Ma siamo veramente sicuri di comprendere a fondo che cosa significa questo concetto e come applicarlo correttamente?

A distanza di quasi vent’anni dalla pubblicazione dell’agile manifesto, il concetto del feature team rimane ancora valido, ma sembra essersi svuotato della sua iniziale sostanza. Quando si smarrisce il senso dei “perché?”, si perdono di vista anche i valori che ci hanno orientato verso una determinata soluzione. E quando questi valori vengono dimenticati, la soluzione degrada, riaffiorando – camuffata – come lo stesso problema che si intendeva risolvere.

Questo articolo ha la speranza di riordinare le idee, ricostruendo le origini del termine e, di conseguenza, capire in profondità che cosa sono davvero i “feature teams” e da quali figure sono composti: i Product Developer.

Cosa sono i Feature Teams

Metriche legate al lead time, e perché è importante

Come in ogni contesto di prodotto che si rispetti, partiamo dagli impatti e dalle metriche per misurarli.

Qui di seguito riporto delle popolari metriche spesso utilizzate per misurare gli avanzamenti del product backlog:

  • Lead Time: la differenza tra il momento in cui un product backlog item viene creato e quello in cui l’elemento raggiunge il suo stato finale;
  • Planning Time:  la differenza tra il momento in cui un product backlog item viene creato al momento in cui passa “in progress”;
  • Cycle Time: la differenza tra il momento in cui un product backlog item è considerato “in progress” e quello in cui l’elemento raggiunge il suo stato finale.

Per chi ama le formule matematiche, ecco le definizioni:

  • Lead time = Data di fine – Data di creazione
  • Planning time = Data di inizio – Data di creazione
  • Cycle time = Data di fine – Data di inizio
  • Lead time = Cycle time + Planning time
  • Time-to-market ≈ Lead time

In altre parole, il nostro Time-to-market (TTM, tempo tra l’ideazione di un item e la sua effettiva commercializzazione) è direttamente proporzionale al lead time del nostro product team. Sebbene il lead time non sia l’unico fattore che influenzi il TTM, in questo articolo mi concentrerò principalmente sulla relazione generata da questi due elementi.

Queste metriche sono fondamentali per la sopravvivenza di un prodotto nel tempo: riflettono la capacità di adattarsi rapidamente ai cambiamenti del mercato, una caratteristica che viene definita “adattabilità”.

“Adattabilità”: un sinonimo più desueto del familiare termine “agilità”

  • Secondo l’agile manifesto, l’obiettivo è la creazione di un team che sia altamente responsivo al cambiamento;
  • Prendendo in prestito invece terminologie proprie della cultura lean, l’adattabilità è uno dei principali valori che un’organizzazione dovrebbe inseguire;
  • Sono invece classificati come “sprechi” (i famosi “lean waste”) tutti i fattori che ci portano ad allontanarci da questa metrica. (* vedi nota in fondo al paragrafo).

Al di là dei discorsi teorici, è piuttosto evidente che più siamo in grado di ridurre il tempo che passa da quando abbiamo un’idea fino al momento in cui siamo in grado di realizzarla concretamente, più vantaggi strategici avremo. Oltre a permetterci di arrivare prima di altri sul mercato, diminuisce – ad esempio – il tempo necessario alla validazione di un MVP.

Relazioni del time to market con altre metriche aziendali

Ovviamente, il lead time non è l’unico elemento che ci aiuta ad inseguire la chimera dell’adattabilità. Di seguito riporto un diagramma che mostra alcune relazioni del time to market con altre metriche aziendali. Ogni freccia indica un rapporto di diretta proporzionalità. In verde sono riportate le metriche di delivery, in altri colori quelle legate al marketing, discovery ed altro.

Time-to-market ed esempi di metriche dipendenti

Sono molti i discorsi che si potrebbero avviare, e ognuna delle frecce riportate in questo diagramma potrebbe dare origine ad un nuovo articolo per Product Heroes. In questa sede mi accontenterò di prendere in esame il lead time, che – non sorprenderà – è strettamente legato alla struttura organizzativa del nostro dev team.

Vediamo cosa c’entra tutto questo con i temibili “component team”; ma prima di entrare nel vivo dell’argomento… parliamo di autostrade.

(*). Piccola nota doverosa. Se è vero che ridurre il lead time è nostra preoccupazione primaria, è anche vero che l’agile manifesto sottolinea l’importanza di generare valore “ad un passo sostenibile”.

E’ comprovato che NON si aumenta il lead time:

  • Facendo fare straordinari;
  • Lavorando nel weekend;
  • Parallelizzando le attività con un numero smodato di sviluppatori (come non citare il trito e ritrito motto “nove madri non fanno un figlio in un mese”);
  • Ingaggiando opache software house con tariffe stracciate.

L’obiettivo è lo sviluppo di un dev team vicino al business per cui lavora, in grado di generare valore per un tempo indefinito, senza andare in sofferenza. Per questo vi prego: non andate in giro a dire che state stressando i vostri sviluppatori perché vi ho convinto a ridurre il lead time!

Queuing theory: la teoria delle code per comprendere le interazioni in un team di sviluppo prodotto

Stiamo guidando in autostrada, il traffico è scorrevole. Il paesaggio intorno a noi scivola placidamente attraverso i nostri finestrini, trasmettendoci un senso di libertà che solo una lunga strada che si srotola sa promettere. La vita è bella. 

Improvvisamente iniziamo a rallentare. Il tempo di arrivo segnato sul navigatore cresce vertiginosamente e si colora di un allarmante rosso. Il traffico si congestiona, il numero di automobili intorno a noi aumenta finché – improvvisamente – siamo fermi: è una coda!

Sappiamo sulla nostra pelle che una coda si forma in brevi attimi ma richiede solitamente molto più tempo per essere smaltita. Questo interessante fenomeno è studiato dalla “teoria delle code”. La teoria delle code (queueing theory), ovvero la teoria matematica che descrive come gli oggetti si spostano attraverso le code, è stata sviluppata per comprendere e migliorare i flussi nei sistemi di telecomunicazione. Questi modelli, caratterizzati da alta variabilità e casualità, risultano piuttosto calzanti per descrivere le modalità di interazione tra gli individui di un team di sviluppo prodotto.

Le code hanno caratteristiche bizzarre e sorprendenti:

  • Non linearità: quando l’autostrada è occupata dallo 0% al 50%, il traffico scorre agevolmente. Tuttavia, tra il 50% e il 100%, il rallentamento diventa evidente e la coda si forma rapidamente, bloccando quasi completamente il traffico;
  • Ritardo e sovraccarico: il rallentamento non inizia al 99% di utilizzo della capacità della strada, ma avviene molto prima che si raggiunga la capienza massima;
  • Non determinismo: il comportamento delle code è imprevedibile e tende a variare in modo casuale.

Ogni volta che il nostro team dimostra una dipendenza verso una risorsa, un sistema o un altro team, ci troviamo di fronte a una coda: overhead organizzativi, handoff o passaggi di consegne, duplicazioni, manutenzioni non necessarie e complessità di coordinamento sono alcuni esempi.

Più in generale, ogni coda è legata alla presenza di un lavoro incompleto in attesa di essere nuovamente preso in carico, un “work in progress” (WIP). I work in progress rappresentano un noto “spreco” secondo la cultura lean, dato che contribuiscono ad aumentare la taglia dell’inventario e, perciò, richiedono un investimento di tempo e denaro per essere smaltiti. Di conseguenza, diminuiscono la generazione del valore ed aumentano il cycle time.

Feature Team VS Component Team

Torniamo al nostro tema iniziale: perché i feature team? 

Il termine feature team (o team cross-funzionale) fu reso popolare da Microsoft nel 1980 e discusso in Microsoft Secrets di Jim Carthy:

 Feature teams are about empowerment, accountability, identity, consensus and balance.

Mentre Jim Highsmith, in Agile Project Management dice:

Feature based delivery means that the engineering team builds customer centric features of the final product.

Immaginiamo che la nostra struttura organizzativa non sia composta da feature teams, ma da component teams, organizzati secondo le loro competenze tecniche. Avremo, quindi, un team backend, frontend, data analyst, business analyst e designer.

Sembra evidente che stiamo introducendo una serie di dipendenze e di comportamenti che danno origine alla non linearità che abbiamo appena descritto nella teoria delle code. Ogni team è munito del proprio backlog (eg. la propria coda) e quindi il passaggio di una user story attraverso i team assomiglierà a qualcosa del genere:

Tragica storia di un product backlog item che attraversa quattro component team.

Per arrivare nel suo stato di completamento, un elemento del backlog deve essere processato da tutte le code dei singoli team: prima nella coda di lavoro del business analyst, poi in quella degli sviluppatori backend e così via, fino alla produzione.

La matematica sottostante alla teoria delle code ci dice che il tempo ha una relazione più che lineare rispetto al numero di code: in altre parole, più code abbiamo, più il tempo speso nelle transizioni aumenta esponenzialmente. Inoltre, come abbiamo visto, le code iniziano a congestionare il traffico ben prima che la loro piena capacità sia raggiunta.

Ogni coda crea un ritardo che inibisce il flusso: se non ci fossero code (né alcun tipo di multitasking che trasmetta l’erronea concezione che non ce ne siano), il sistema si muoverebbe in maniera fluida ed i principi lean verrebbero applicati alla perfezione, senza alcun ritardo. Gli ingorghi che notiamo nelle code su strada si verificano nello stesso modo anche alle dinamiche fra gruppi di lavoro in dipendenza l’uno dall’altro. Dipendenze, ritardi, regressioni, accumuli di lavoro.

Esempi di code nello sviluppo e gestione di un prodotto:

  • Specifiche in attesa di essere implementate;
  • Documenti di design in attesa di sviluppo;
  • Codice in attesa di test;
  • Codice di un singolo sviluppatore in attesa di integrazione con quello di altri sviluppatori (branch, pull request…);
  • Grandi componenti in attesa di essere integrati;
  • Grandi componenti e sistemi in attesa di test;

Nella storia dello sviluppo software i componenti team sono stati abbandonati in favore dei più agili feature team proprio perché permettono di eliminare in maniera più efficace le code ed i WIP. 

Gli svantaggi dei component teams

  • Promuove un modello di lavoro sequenziale;
  • Limita l’apprendimento delle persone, facendole lavorare sulla stessa cosa per lungo tempo;
  • Provoca lunghi rallentamenti a causa di attese e sprechi di hand-off;
  • Incoraggia la duplicazione di codice;
  • Incoraggia la crescita eccessiva di sviluppatori;
  • Complica il planning e la sincronizzazione;
  • Aumenta i colli di bottiglia – single point of success are also single point of failure;
  • Produce codice più povero.

Questo è il motivo per cui i teorici della agilità hanno abbandonato l’idea di una struttura organizzativa component team verso una strutturata a feature team.

Feature Team (ma siamo sicuri?)

Eureka! Abbiamo quindi abbandonato una struttura organizzativa disfunzionale piena di dipendenze e rallentamenti per dare spazio a una in cui tutte le nostre squadre di sviluppo sono organizzate in feature team completamente autonomi. Ma ci siamo veramente liberati delle code?

Riunire tutte le competenze necessarie in unità di sviluppo indipendenti è sicuramente il primo passo, ma è sufficiente? Consideriamo un fittizio feature team composto da uno sviluppatore frontend, backend ed un data scientist.

Come sarà organizzato il product backlog di questo team? E’ lecito pensare che avremo dei product backlog item assegnati a ciascuna di queste figure, ed ognuno dei loro task sarà aderente alla specialità tecnologica degli sviluppatori. Questo è un esempio di “coda implicita”: sulla carta abbiamo un product backlog unificato, ma di fatto è come se ne avessimo tre, compartimentalizzati ma dipendenti l’uno dell’altro. Nuove code!

Fenomeno dei backlog impliciti in un team composto da component people

Organizzando il nostro team semplicemente accorpando sviluppatori a singola specialità, non abbiamo fatto altro che scambiare i nostri component team per delle squadre composte da component people. Di fatto, il processo di eliminazione delle code è avvenuto in maniera soltanto parziale, perché ogni individuo è ora munito della propria coda indipendente, ugualmente disfunzionale quanto quella che avevamo prima.

Capiamo quindi che l’organizzazione in feature team non è semplicemente un modo diverso di raggruppare le persone: deve produrre un cambio culturale, relativo soprattutto allo sviluppo delle carriere e delle professionalità dei singoli elementi del team.

Feature Team VS Component Team: qual è dunque la soluzione?

Feature Team VS Component Team e il ruolo del Product Developer

Il Product Developer è un professionista dotato delle competenze necessarie per progettare e sviluppare autonomamente una funzionalità di prodotto in maniera verticale. 

Un Feature Team composto da Product Developers non include quindi alcun membro che sia esclusivamente sviluppatore, analista o tester; piuttosto, è formato da professionisti la cui competenza principale sarà affiancata ad altre abilità trasversali.

Un architetto software, ad esempio, potrebbe scrivere test automatici, mentre un tester potrebbe svolgere anche il ruolo di analista. Per definizione, non esistono titoli specifici, e non si dà enfasi a nessuna classificazione all’interno del team.

Un comune fraintendimento riguardo al Product Developer (in specifici contesti anche chiamato “full-stack developer”) è che porti alla formazione di un team composto da generalisti senza alcuna profonda competenza in alcun campo. Al contrario, il saper spaziare su vari domini non impedisce in alcun modo di essere uno specialista in un ambito verticale; di quest’ultimo si acquisisce anzi maggiore cognizione grazie alla comprensione delle discipline ad esso legate. 

Resta comunque chiaro che solo collettivamente il team può coprire tutte le competenze necessarie per intervenire sulla codebase, ma questo non deve essere una scusa per non sconfinare nelle zone grigie in cui avviene la più vera e virtuosa contaminazione. Qualora incontrasse ostacoli, il singolo Product Developer può contare sul supporto dei colleghi di squadra, altrettanto versatili nel navigare tra i vari componenti del prodotto, evitando così il rischio di dipendenze dannose come descritto nella teoria delle code.

Il ruolo del Product Developer e la sua anima “analista”

Oltre ad essere esperti tecnici, ci si aspetta che il Product Developer sia abile nel gestire questioni funzionali del prodotto ed analizzare nuovi processi.

Il Product Developer è in grado di condurre interviste con gli utenti finali (essenzialmente svolgendo il ruolo di business analyst e, in parte, di user researcher), trasformando i requisiti di alto livello forniti dal Product Manager in elementi del backlog dettagliati e lavorabili. 

Questo aspetto è altrettanto cruciale quanto quello tecnico. Il “trasporto” è classificato dalla cultura lean come spreco e, nel contesto del software, ciò si manifesta nella trasmissione di informazioni a persone specifiche. In quanto incaricati della realizzazione, gli sviluppatori sono la risorsa finale a cui dovranno convergere tutte le informazioni del prodotto. E’ per questa ragione che minimizzare i processi di trasmissione delle informazioni è fondamentale per ridurre il lead time.

Il modo migliore per raggiungere questo obiettivo è mantenere gli sviluppatori il più vicino possibile agli utenti finali per i quali stanno sviluppando il software. Da qui l’anima “analista” che ogni sviluppatore non deve mai tralasciare.

Questo comporta un cambio di mentalità che potrebbe estendersi anche a figure fuori dal mondo dello sviluppo, le quali potrebbero acquisire competenze più tecniche per offrire supporto al team. Ad esempio, un business analyst potrebbe sviluppare competenze sufficienti per eseguire query su database o sul sistema utilizzato per raccogliere telemetria e analytics.

Ecco alcune figure mitologiche che potrebbero ricadere nella dicitura Product Developer:

  • Un designer con competenze di sviluppo frontend (o uno sviluppatore frontend con competenze di design)
  • Un tester business analyst
  • Sviluppatore frontend e backend (il famoso fullstack developer)
  • Data scientist con buone competenze di object oriented programming e software design
  • Un business analyst in grado di comporre query SQL

Sono certo che queste figure professionali non siano semplici esercizi teorici: la certezza della mia convinzione mi viene dal puro e semplice fatto di averle viste tutte in carne ed ossa: sono miei colleghi!

Ma vediamo quali cambi culturali sono necessari ad un’organizzazione per produrre questo genere di figure professionali.

Cambio di Mentalità

Mono zukuri wa hito zukuri (Making things is about making people)

Isao Kato, studente di Taichi Ohno (padre del sistema produttivo Toyota)

E’ molto frequente, specialmente in ambienti piuttosto tradizionalisti, che l’idea di un Product Developer, T-shaped, V-shaped, H-shaped (o qualunque altra lettera vi venga in mente) sia molto contestata o rapidamente bollata come irrealizzabile.

Perché è così difficile accettare l’idea di un Product Developer capace di spaziare tra diverse aree di competenza? Perché le strutture organizzative si oppongono così apertamente alla possibilità di abbattere le barriere?

I detrattori di questa scuola di pensiero sostengono prevalentemente due tesi:

  1. E’ impossibile che le vaste e numerose responsabilità della tecnologia possano essere condivise da meno di X persone (leggasi X come un numero arbitrario dettato dalla sensibilità di chi parla);
  2. Le persone non possono o non vogliono imparare nuove skill;

Fortunatamente, la prima supposizione è diventata sempre più obsoleta grazie all’avvento di pratiche agile come Continuous Integration/Continuous Deployment (CI/CD) e Test-Driven Development (TDD). Grazie ai progressi tecnologici, ora disponiamo degli strumenti necessari per affrontare il sovraccarico di compiti che gli sviluppatori devono gestire, a condizione di investire adeguatamente nell’automazione.

Questo ci consente di ottimizzare il processo di sviluppo, migliorare la qualità del codice e ridurre il rischio di errori, liberando gli sviluppatori da compiti ripetitivi e consentendo loro di concentrarsi su attività di valore. Tutto ciò è reso ancora più vero dall’avvento dei copilot AI, che renderanno via via sempre più semplice acquisire nuove abilità ed integrarle alle proprie.

Per quanto riguarda la seconda questione, l’idea che uno sviluppatore (o, in generale, un individuo) sia limitato a maturare una sola competenza verticale è non solo errata, ma anche pericolosa (non tanto per lo sviluppo del prodotto quanto per la crescita professionale dei singoli).

Non è raro che questa opinione venga spesso proprio da quegli specialisti “singoli” che si oppongono a questi modelli, non tanto per una reale convinzione, quanto per difendere lo status quo della loro seniority (eg. “è difficile fare capire a qualcuno qualcosa se il suo lavoro dipende dal non capirla”). 

L’essere umano è naturalmente “full-stack”

Se pensiamo a noi stessi, ognuno di noi possiede una vasta gamma di competenze verticali. Personalmente, ad esempio, ho una profonda conoscenza nello sviluppo di prodotti digitali, ma anche competenze in recitazione, ed una buona conoscenza della storia delle religioni antiche. Parlo italiano come lingua madre, sono fluente in una lingua secondaria e ho un’infarinatura su altre due. Se questa varietà è presente nella sfera personale, perché non dovrebbe esserci anche in quella lavorativa? Perché non potremmo avere sviluppatori front-end che sono anche esperti di accessibilità, o business analyst in grado di condurre autonomamente una discovery sui dati in un database SQL?

Sebbene l’essere umano tenda naturalmente a sviluppare un vasto insieme di competenze, il mondo del lavoro spesso è polarizzato nel credere che ciò non sia possibile. Ciò richiede una revisione dei percorsi di carriera, che troppo spesso si concentrano esclusivamente su un approfondimento verticale in una singola area tematica.

Questo approccio ha certamente il suo valore, ma non sarebbe altrettanto gratificante se i nostri percorsi di crescita professionale fossero legati anche alla diversificazione delle competenze? Immaginiamo per un momento che le nostre valutazioni e i nostri aumenti salariali fossero basati su questo principio: se venissimo retribuiti per imparare il maggior numero possibile di competenze saremmo tutti dei fortissimi Product Developer in meno di tre anni. 

Conclusioni

  • Ottimizzare il lead time è una delle componenti che aiutano a diminuire il time-to-market
  • I component team introducono almeno una “coda” per team.
  • Il lead time peggiora all’aumentare delle dipendenze e del numero di “code”. 
  • La trasmissione delle informazioni e dei task è uno spreco lean.
  • Un team composto da professionisti a singola responsabilità non è un feature team, è un team di component people, con gli stessi identici problemi di un component team standard.
  • Rimuovere gli sprechi lean è possibile solo con un feature team composto da Product Developer.
  • Il Product Developer esiste, è possibile!

E voi, che ne pensate? Come sono organizzati i vostri team? Fatecelo sapere nei commenti 😉

2 commenti per “Feature Team VS Component Team e il ruolo del Product Developer: tutto quello che c’è da sapere

  • Vincenzo

    COMPLETAMENTE D’ACCORDO!
    Inoltre quello che il mercato richiede è proprio quello che i Feature Teams riescono a “deliverare”.
    Con l’aiuto di uno Scrum Master o un Agile Coach o un semplice team leader questo cambio di cultura dovrebbe esserci ormai in tutti i team di sviluppo, soprattutto di prodotto.

  • Francesco

    L’idea di utilizzare “product developers” con competenze trasversali presenta diverse criticità. Sovraccaricare i singoli sviluppatori con ruoli multipli rischia di compromettere la qualità del lavoro e aumentare il burnout. La mancanza di specializzazione potrebbe portare a una superficialità nelle competenze tecniche. Volendo essere maliziosi, sembra esserci una ricerca di ottimizzare i costi addossando a pochi tutte le attività che dovrebbero essere svolte da più persone. Questo potrebbe portare all’alienazione delle persone, trovandosi da sole a gestire attività pensate per essere affrontate in team.

Dicci cosa ne pensi

Le slide sono disponibili per studenti ed ex studenti del Master in Product Management

Accedi a "Agile Starter Kit" Gratis

Iscriviti alla newsletter e accedi ad Agile Starter Kit: la cartella che contiene oltre 70 pagine su Agile, Scrum / Kanban, Organizzazione Team, User Story, Backlog, e tutto ciò che ti serve per partire.

Scarica il post sulle alternative a Scrum

Iscriviti alla newsletter e scarica gratuitamente il post "Agile Scrum: Alternative più flessibili e agili"